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Foreword 


This  background  paper  was  prepared  as  part  of  the  Office  of  Tech¬ 
nology  Assessment’s  follow-on  assistance  to  the  Senate  Com¬ 
mittee  on  Governmental  Affairs,  subsequent  to  release  of  the 
September  1 994  OTA  report  Information  Security  and  Privacy  in 
Network  Environments.  The  Committee  requested  additional  informa¬ 
tional  and  analytical  assistance  from  OTA  in  order  to  prepare  for  hear¬ 
ings  and  legislation  in  the  104th  Congress. 

This  background  paper  updates  and  develops  some  key  issues  that 
OTA  had  identified  in  its  earlier  report,  in  light  of  recent  developments  in 
the  private  sector  and  in  government.  During  the  course  of  this  work, 
OTA  found  that  the  need  for  timely  attention  to  the  security  of  unclassi¬ 
fied  information  has  intensified  in  the  months  since  the  1994  report  was 
issued. 

OTA  appreciates  the  participation  of  many  individuals  without  whose 
help  this  background  paper  would  not  have  been  possible.  OTA  received 
valuable  assistance  from  workshop  participants  and  many  other  re¬ 
viewers  and  contributors  from  government,  academia,  and  industry.  The 
background  paper  itself,  however,  is  the  sole  responsibility  of  OTA. 
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Introduction 

and 

Summary 


Controversies,  problems,  and  proposed  solutions  related  to 
information  security  and  privacy  are  becoming  increas¬ 
ingly  prominent  among  government,  business,  academia, 
and  the  general  public.  At  the  same  time,  use  of  informa¬ 
tion  networks  for  business  has  continued  to  expand,  and  ventures 
to  bring  electronic  commerce  and  “electronic  cash”  into  homes 
and  offices  are  materializing  rapidly.1  Government  agencies  have 
continued  to  expand  both  the  scale  and  scope  of  their  network 
connectivities;  information  technologies  and  networks  are  fea¬ 
tured  prominently  in  plans  to  make  government  more  efficient, 
effective,  and  responsive.2 

Until  recently,  topics  such  as  intrusion  countermeasures  for 
computer  networks  or  the  merits  of  particular  encryption  tech¬ 
niques  were  mostly  of  interest  to  specialists.  However,  in  the  past 


1  See,  e.g.,  Randy  Barrett,  “Hauling  in  the  Network — Behind  the  World’s  Digital  Cash 
Curve,”  Washington  Technology ,  Oct.  27,  1994,  p.  18;  Neil  Munro,  “Branch  Banks  Go 
Way  of  the  Drive-In,”  Washington  Technology ,  Feb.  23,  1995,  pp.  1,48;  Amy  Cortese  et 
al.,  “Cashing  In  on  Cyberspace:  A  Rush  of  Software  Development  To  Create  an  Electronic 
Marketplace,”  Business  Week ,  Feb.  27, 1995,  pp.  78-86;  Bob  Metcalfe,  “Internet  Digital 
Cash — Don’t  Leave  Your  Home  Page  Without  It,”  InfoWorld ,  Mar.  13, 1995,  p.  55;  “Net¬ 
scape  Signs  Up  19  Users  for  Its  System  of  Internet  Security,”  The  Wall  Street  Journal,  Mar. 
20, 1995,  p.  B3;  Saul  Hansell,  “VISA  Will  Put  a  Microchip  in  New  Cards — Product  Is  De¬ 
signed  for  Small  Purchases,”  The  New  York  Times,  Mar.  21, 1995,  p.  D3;  Jorgen  Wouters, 
“Brother,  Can  You  Spare  a  Virtual  Dime?”  Washington  Technology ,  Mar.  23, 1995,  pp.  1, 
44. 

2  See,  e.g.,  Neil  Munro,  “Feds  May  Get  New  Infotech  Executive,”  Washington 
Technology ,  Feb.  23,  1995,  pp.  1,  49;  Charles  A.  Bowsher,  Comptroller  General  of  the 
United  States,  “Government  Reform:  Using  Reengineering  and  Technology  To  Improve 
Government  Performance,”  GAO/T-OCG-95-2,  testimony  before  the  Committee  on 
Governmental  Affairs,  U.S.  Senate,  Feb.  2, 1995;  and  Elena  Varon,  “Reinventing  Is  Old 
Hat  for  New  Chairman,”  Federal  Computer  Week ,  Feb.  20,  1995,  pp.  22,  27. 
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few  years,  stories  about  controversial  federal  en¬ 
cryption  standards,  “password  sniffing”  and  un¬ 
authorized  intrusions  on  the  Internet,  the  pursuit 
and  capture  of  a  notorious  computer  “cracker,” 
and  export  controls  on  computer  programs  that 
perform  encryption  have  become  front-page 
news.3 

The  increased  visibility  and  importance  ac¬ 
corded  information  security  and  privacy  protec¬ 
tion  (see  box  1-1)  reflect  a  number  of  institutional, 
social,  and  technological  changes  that  have  made 
information  technologies  critical  parts  of  daily 
life.4  We  are  in  transition  to  a  society  that  is  be¬ 
coming  critically  dependent  on  electronic  in¬ 
formation  and  network  connectivity.  This  is 
exemplified  by  the  explosive  growth  of  the  Inter¬ 
net,  which  now  has  host  computers  in  over  85 
countries,  as  well  as  the  rapidly  expanding  variety 
of  online  sources  of  information,  services,  and  en¬ 
tertainment.  The  growing  dependence  of  both  the 
public  and  private  sectors  on  electronic  informa¬ 
tion  and  networking  makes  the  ability  to  safe¬ 
guard  information  and  provide  adequate  privacy 
protections  for  individuals  absolutely  essential. 

In  September  1994,  the  Office  of  Technology 
Assessment  (OTA)  released  the  report  Informa¬ 
tion  Security  and  Privacy  in  Network  Environ¬ 
ments  (see  box  1-2). 5  That  report  was  prepared  in 
response  to  a  request  by  the  Senate  Committee  on 
Governmental  Affairs  and  the  House  Subcommit¬ 
tee  on  Telecommunications  and  Finance.  The 


need  for  congressional  attention  to  safeguarding 
unclassified  information  has  been  reinforced  in 
the  months  since  the  release  of  the  OTA  report. 

INTRODUCTION 

This  background  paper  is  part  of  OTA’s  follow-on 
assistance  to  the  Senate  Committee  on  Govern¬ 
mental  Affairs  after  the  September  1994  OTA  re¬ 
port  on  information  security  and  privacy.  The 
Committee  had  requested  additional  information¬ 
al  and  analytical  assistance  from  OTA  in  order  to 
prepare  for  hearings  and  legislation  in  the  104th 
Congress  (see  the  letter  of  request  in  appendix  A). 

This  background  paper  is  a  companion  and  sup¬ 
plement  to  the  1994  report  and  is  intended  to  be 
used  in  conjunction  with  it.  For  the  reader’s  con¬ 
venience,  however,  pertinent  technical  and  insti¬ 
tutional  background  material,  drawn  from  that 
report  and  updated  where  possible,  is  included  in 
this  background  in  appendices  B  (“Federal  In¬ 
formation  Security  and  the  Computer  Security 
Act”),  C  (“U.S.  Export  Controls  on  Cryptogra¬ 
phy”),  and  D  (“Summary  of  Issues  and  Options 
from  the  1994  OTA  Report”). 

One  purpose  of  this  background  paper  is  to  is  to 
update  some  key  issues  that  OTA  had  identified  in 
the  report,  in  light  of  recent  developments.  Anoth¬ 
er  purpose  is  to  develop  further  some  of  OTA’s 
findings  and  options,  particularly  as  these  relate  to 
the  effects  of  government  policies  on  the  private 


3  See  John  Markoff,  “Flaw  Discovered  in  Federal  Plan  for  Wiretapping,”  The  New  York  Times,  June  2,  1994,  pp.  1,  D17;  Peter  H.  Lewis, 
“Hackers  on  Internet  Posing  Security  Risks,  Experts  Say,”  The  New  York  Times,  July  21,  1994,  pp.  1,  BIO;  John  Markoff,  “A  Most-Wanted 
Cyberthief  Is  Caught  in  His  Own  Web,”  The  New  York  Times ,  Feb.  16,  1995,  pp.  1 ,  D17;  and  John  Schwartz,  “Privacy  Program:  An  On-Line 
Weapon?”  The  Washington  Post,  Apr.  3,  1995,  pp.  Al,  A 13.  See  also  Jared  Sandberg,  “Newest  Security  Glitch  on  the  Internet  Could  Affect 
Many  ‘Host’  Computers,”  The  Wall  Street  Journal,  Feb.  23, 1995,  p.  B8;  Jared  Sandberg,  “Immorality  Play:  Acclaiming  Hackers  as  Heroes,” 
The  Wall  Street  Journal,  Feb.  27,  1995,  p.  Bl,  B8;  and  Amy  Cortese  et  al.,  “Warding  Off  the  Cyberspace  Invaders,”  Business  Week,  Mar.  13, 
1995,  pp.  92-93. 

4  See  U.S.  Congress,  Office  of  Technology  Assessment,  Making  Government  Work:  Electronic  Delivery  of  Government  Services,  OTA- 
TCT-578  (Washington,  DC:  U.S.  Government  Printing  Office,  September  1993);  Electronic  Enterprises:  Looking  to  the  Future,  OTA-TCT-600 
578  (Washington,  DC:  U.S.  Government  Printing  Office,  May  1994);  and  Wireless  Technologies  and  the  National  Information  Infrastructure 
(forthcoming,  1995).  See  also  U.S.  General  Accounting  Office,  Information  Superhighway:  An  Overview  of  Technology  Challenges,  GAO/ 
AIMD-95-23  (Washington,  DC:  U.S.  General  Accounting  Office,  January  1995). 

5  U.S.  Congress,  Office  of  Technology  Assessment,  Information  Security  and  Privacy  in  Network  Environments,  OTA-TCT-606  (Washing¬ 
ton,  DC:  U.S.  Government  Printing  Office,  September  1994).  Available  from  OTA  Online  via  anonymous  file  transfer  protocol  (ftp://otabbs. 
ota.gov/pub/information.security/)  or  World  Wide  Web  (http://www.ota.gov). 
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BOX  1  -1 :  Some  Notes  on  Tcrrriinology 


Information  Security 

There  are  three  main  aspects  of  information  security:  1)  confidentiality,  2)  integrity,  and  3)  availability 
These  protect  against  the  unauthorized  disclosure,  modification,  or  destruction  of  information.  The  focus  of 
this  background  paper,  and  the  OTA  report  Information  Security  and  Privacy  in  Network  Environments 
(September  1994)  that  it  supplements,  is  technical  and  institutional  measures  to  ensure  the  confidentiality 
and  integrity  of  unclassified  electronic  Information  in  networks,  not  the  security  of  the  networks  themselves. 
Network  reliability  and  survivability  (related  to  ‘(availability”)  were  not  addressed;  these  topics  are  expected 
to  be  the  focus  of  subsequent  OTA  work. 

Confidentiality  and  Privacy 

OTA  uses  the  term  confidentiality  to  refer  to  disclosure  of  information  only  to  authorized  individuals, 
entities,  and  so  forth.  Privacy  refers  to  the  social  balance  between  an  individual’s  right  to  keep  information 
confidential  and  the  societal  benefit  derived  from  sharing  information,  and  how  this  balance  is  codified  to 
give  individuals  the  means  to  control  personal  information.  The  terms  are  not  mutually  exclusive:  safe¬ 
guards  that  help  ensure  confidentiality  of  information  can  be  used  to  protect  personal  privacy. 

information  Safeguards  and  Security 

OTA  often  uses  the  term  safeguard,  as  in  ‘(information  safeguards”  or  ‘(to  safeguard  information.”  This  is 
to  avoid  misunderstandings  regarding  use  of  the  term  “security,”  which  some  readers  may  interpret  in 
terms  of  classified  information,  or  as  excluding  measures  to  protect  personal  privacy.  In  discussion  of  in¬ 
formation  safeguards,  the  focus  here  is  on  technical  and  institutional  measures  to  ensure  the  confidentiality 
and  integrity  of  the  information,  and  also  the  authenticity  ot  its  origin. 

Cryptography  can  be  used  to  fulfill  these  functions  for  electronic  information.  Modern  encryption  tech¬ 
niques,  for  example,  can  be  used  to  safeguard  the  confidentiality  of  the  contents  of  a  message  (or  a  stored 
file).  Integrity  is  used  to  refer  to  the  property  that  the  information  has  not  been  subject  to  unauthorized  or 
unexpected  changes.  Authenticity  refers  to  the  property  that  the  message  or  information  comes  from  the 
stated  source  or  origin.  Message  authentication  techniques  and  digital  signatures  based  on  cryptography 
can  be  used  to  ensure  the  integrity  of  the  message  (that  it  has  been  received  exactly  as  it  was  sent)  and 
the  authenticity  of  its  origin  (that  it  comes  from  the  stated  source). 

SOURCE:  Office  of  Technology  Assessment,  1995.  For  more  detailed  discussion  of  cryptographic  safeguards,  see  OTA,  Information 
Security  _  ,d  Privacy  in  Network  Environments  (OTA-TCT-606,  September  1994),  esp.  ch.  2  and  4  and  appendix  C. 


sector  and  to  federal-agency  operations  to  safe¬ 
guard  unclassified  information.  As  in  the  1994  re¬ 
port,  the  focus  is  on  safeguarding  unclassified 
information.  OTA’s  follow-on  activities  were  con¬ 
ducted  at  the  unclassified  level  and  project  staff 
did  not  receive  or  use  any  classified  information 
during  the  course  of  this  work. 

Chapter  2  of  this  background  paper  gives  an 
overview  of  the  1994  report.  It  highlights  the  im¬ 
portance  of  information  security  and  privacy 
issues,  explains  why  cryptography  and  cryptogra¬ 
phy  policies  are  so  important,  and  reviews  policy 


findings  and  options  from  the  1994  report.  Chap¬ 
ter  3  identifies  major  themes  that  emerged  from  a 
December  1994  OTA  workshop,  particularly  re¬ 
garding  export  controls  and  the  international  busi¬ 
ness  environment,  federal  cryptography  policy, 
and  information-security  “best  practices.”  Chap¬ 
ter  4  provides  an  update  on  recent  and  ongoing 
cryptography,  privacy,  and  security-policy  devel¬ 
opments  and  their  relevance  for  possible  congres¬ 
sional  actions. 
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BOX  1-2:  The  1994  OTA  Re 


In  September  1994,  the  Office  of  Technology  Assessment  released  its  report  Information  Security  and 
Privacy  in  Network  Environments. In  that  report,  OTA  found  that  the  fast-changing  and  competitive  market¬ 
place  that  produced  the  Internet  and  strong  networking  and  software  industries  in  the  United  States  has  not 
consistently  produced  products  equipped  with  affordable,  user-friendly  safeguards.  Many  individual  prod¬ 
ucts  and  techniques  are  available  to  adequately  safeguard  specific  information  networks,  if  the  user  knows 
what  to  purchase,  and  can  afford  and  correctly  use  the  product,  Nevertheless,  better  and  more  affordable 
products  are  needed.  In  particular,  OTA  found  a  need  for  products  that  integrate  security  features  with 
other  functions  for  use  in  electronic  commerce,  electronic  mail,  or  other  applications. 

OTA  found  that  more  study  is  needed  to  fully  understand  vendors’  responsibilities  with  respect  to  soft¬ 
ware  and  hardware  product  quality  and  liability.  OTA  also  found  that  more  study  is  also  needed  on  the 
effects  of  export  controls  on  the  domestic  and  global  markets  for  information  safeguards,  and  on  the  ability 
of  safeguard  developers  and  vendors  to  produce  more  affordable,  integrated  products.  OTA  concluded 
that  broader  efforts  to  safeguard  networked  information  will  be  frustrated  unless  cryptography-policy  is¬ 
sues  are  resolved. 

OTA  found  that  the  single  most  important  step  toward  implementing  proper  safeguards  for  networked 
information  in  a  federal  agency  or  other  organization  is  for  top  management  to  define  the  organization’s 
overall  objectives,  define  an  organizational  security  policy  to  reflect  those  objectives,  and  implement  that 
policy.  Only  top  management  can  consolidate  the  consensus  and  apply  the  resources  necessary  to  effec¬ 
tively  protect  networked  information.  For  the  federal  government,  this  requires  guidance  from  the  Office  of 
Management  and  Budget  (e.g.,  in  OMB  Circular  A-130),  commitment  from  top  agency  management,  and 
oversight  by  Congress. 

During  the  course  of  the  assessment  (1993-94),  there  was  widespread  controversy  concerning  the  Clin¬ 
ton  Administration’s  escrowed-encryption  initiative.  The  significance  of  this  initiative,  in  concert  with  other 
federal  cryptography  policies,  resulted  In  an  increased  focus  in  the  report  on  the  processes  that  the  gov¬ 
ernment  uses  to  regulate  cryptography  and  to  develop  federal  information  processing  standards  (the  FIPS) 
based  on  cryptography. 

The  1994  OTA  report  concluded  that  Congress  has  a  vital  role  in  formulating  national  cryptography  policy 
and  in  determining  how  we  safeguard  information  and  protect  personal  privacy  in  an  increasingly  networked 
society  (see  the  expanded  discussion  in  appendix  D  of  this  background  paper).  Policy  issues  and  options 
were  identified  in  three  areas:  1  )  cryptography  policy,  including  federal  information  processing  standards  and 
export  controls:  2)  guidance  on  safeguarding  unclassified  information  in  federal  agencies;  and  3)  legal  issues 
and  information  security,  including  electronic  commerce,  privacy,  and  intellectual  property. 

SOURCE:  Office  of  Technology  Assessment,  1995;  based  on  Information  Security  and  Privacy  in  Network  Environments  (OTA- 
TCT-606,  September  1994). 


INFORMATION  SECURITY  AND 
PRIVACY  IN  A  NETWORKED  SOCIETY 

Information  technologies  are  transforming  the 
ways  in  which  we  create,  gather,  process,  and 
share  information.  Rapid  growth  in  computer  net¬ 
working  is  driving  many  of  these  changes;  elec¬ 
tronic  transactions  and  electronic  records  are 
becoming  central  to  everything  from  business  to 


health  care.  Within  the  federal  government,  effec¬ 
tive  use  of  information  technologies  and  networks 
is  central  to  government  restructuring  and  reform. 

The  transformation  being  brought  about  by  net¬ 
working  brings  with  it  new  concerns  for  the  secu¬ 
rity  of  networked  information  and  for  our  ability 
to  maintain  effective  privacy  protections  in  net¬ 
worked  environments.  Unless  these  concerns  can 
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be  resolved,  they  threaten  to  limit  networking’s 
full  potential  in  terms  of  both  participation  and 
usefulness.  Therefore,  information  safeguards 
(countermeasures)  are  achieving  new  promi¬ 
nence.  Appropriate  safeguards  for  the  networked 
environment  must  account  for — and  anticipate — 
technical,  institutional,  and  social  changes  that  in¬ 
creasingly  shift  responsibility  for  security  to  the 
end  users. 

Computing  power  used  to  be  isolated  in  large 
mainframe  computers  located  in  special  facilities; 
computer  system  administration  was  centralized 
and  carried  out  by  specialists.  In  today’s  net¬ 
worked  environment,  computing  power  is  de¬ 
centralized  to  diverse  users  who  operate  desktop 
computers  and  who  may  have  access  to  comput¬ 
ing  power  and  data  at  remote  locations.  Distrib¬ 
uted  computing  and  open  systems  can  make  every 
user  essentially  an  “insider.”  In  such  a  decentral¬ 
ized  environment,  responsibility  for  safeguarding 
information  is  distributed  to  the  users,  rather  than 
remaining  the  purview  of  system  specialists.  The 
increase  in  the  number  and  variety  of  network  ser¬ 
vice  providers  also  requires  that  users  take  respon¬ 
sibility  for  safeguarding  information,  rather  than 
relying  on  intermediaries  to  provide  adequate 
protection.6 

The  new  focus  is  on  safeguarding  the  informa¬ 
tion  itself  as  it  is  processed,  stored,  and  trans¬ 
mitted.  This  contrasts  with  older,  more  static  or 
insulated  concepts  of  “document”  security  or 
“computer”  security.  In  the  networked  environ¬ 
ment,  we  need  appropriate  rules  for  handling 
proprietary,  copyrighted,  and  personal  informa¬ 
tion — and  tools  with  which  to  implement  them.7 


Increased  interactivity  means  that  we  must  also 
deal  with  transactional  privacy,  as  well  as  prevent 
fraud  in  electronic  commerce  and  ensure  that  safe¬ 
guards  are  integrated  as  organizations  streamline 
their  operations  and  modernize  their  information 
systems. 

I  Importance  of  Cryptography 

Cryptography  (see  box  2-1  on  page  46)  is  not  ar¬ 
cane  anymore.  It  is  a  technology  whose  time  has 
come — in  the  marketplace  and  in  society.  In  its 
modem  setting,  cryptography  has  become  a  fun¬ 
damental  technology  with  broad  applications. 

Modem,  computer-based  cryptography  began 
in  the  World  War  II  era.8  Much  of  this  develop¬ 
ment  has  been  shrouded  in  secrecy;  in  the  United 
States,  governmental  cryptographic  research  has 
historically  been  the  purview  of  the  “national 
security”  (i.e.,  defense  and  intelligence)  commu¬ 
nities.  Despite  two  decades  of  growth  in  nongov¬ 
ernmental  research  and  development,  in  the 
United  States,  the  federal  government  still  has  the 
most  expertise  in  cryptography.  Nevertheless, 
cryptography  is  not  just  a  “government  technolo¬ 
gy”  anymore,  either. 

Because  it  is  a  technology  of  broad  application, 
the  effects  of  federal  policies  about  cryptography 
are  not  limited  to  technological  developments  in 
the  field,  or  even  to  the  health  and  vitality  of  com¬ 
panies  that  produce  or  use  products  incorporating 
cryptography.  Instead,  these  policies  will  increas¬ 
ingly  affect  the  everyday  lives  of  most  Americans. 

Encryption  (see  box  2-2  on  page  48)  transforms 
a  message  or  data  files  into  a  form  that  is  unintelli- 


6  The  trend  is  toward  decentralized,  distributed  computing,  rather  than  centralized,  mainframe  computing.  Distributed  computing  is  rela¬ 
tively  informal  and  “bottom  up,”  compared  with  mainframe  computing,  and  systems  administration  may  be  less  rigorous.  See  OTA,  op.  cit., 
footnote  5,  pp.  3-5, 25-32. 

7  See  ibid.,  chapter  3.  “Security”  technologies  like  encryption  can  be  used  to  help  protect  privacy  and  the  confidentiality  of  proprietary 
information;  some,  like  digital  signatures,  could  be  used  to  facilitate  copyright-management  systems. 

8  See,  e.g.,  David  Kahn,  The  Codebreakers  (New  York,  NY:  MacMillan,  1967). 
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gible  without  special  knowledge  of  some  secret 
information  (called  the  “decryption  key”).9  En¬ 
cryption  can  be  used  as  a  tool  to  protect  the 
confidentiality  of  information  in  messages  or 
files — hence,  to  help  protect  personal  privacy. 
Other  applications  of  cryptography  can  be  used  to 
protect  the  integrity  of  information  (that  it  has  not 
been  subject  to  unauthorized  or  unexpected 
changes)  and  to  authenticate  its  origin  (that  it 
comes  from  the  stated  source  or  origin  and  is  not  a 
forgery). 

Thus,  cryptography  is  a  technology  that  will 
help  speed  the  way  to  electronic  commerce.  With 
the  advent  of  what  are  called  public-key  tech¬ 
niques,  cryptography  came  into  use  for  digital  sig¬ 
natures  (see  figure  2-3  on  page  52)  that  are  of 
widespread  interest  as  a  means  for  electronically 
authenticating  and  signing  commercial  transac¬ 
tions  like  purchase  orders,  tax  returns,  and  funds 
transfers,  as  well  as  for  ensuring  that  unauthorized 
changes  or  errors  are  detected  (see  discussion  of 
message  authentication  and  digital  signatures  in 
box  2-2). 10  These  functions  are  critical  for  elec¬ 
tronic  commerce.  Cryptographic  techniques  like 
digital  signatures  can  also  be  used  to  help  manage 
copyrighted  material  in  electronic  form. 1 1 

The  nongovernmental  markets  for  cryptogra¬ 
phy-based  safeguards  have  grown  over  the  past 
two  decades,  but  are  still  developing.  Good  com¬ 
mercial  encryption  technology  is  available  in  the 


United  States  and  abroad.  Research  in  cryptogra¬ 
phy  is  international.  Markets  for  cryptography 
also  would  be  international,  except  for  govern¬ 
mental  restrictions  (i.e.,  export  controls),  that  ef¬ 
fectively  create  “domestic”  and  “export”  market 
segments  for  strong  encryption  products  (see  sec¬ 
tion  on  export  controls  below  and  also  appendix 
C.12  User-friendly  cryptographic  safeguards  that 
are  integrated  into  products  (as  opposed  to  those 
that  the  user  has  to  acquire  separately  and  add  on) 
are  still  hard  to  come  by — in  part,  because  of  ex¬ 
port  controls  and  other  federal  policies  that  seek  to 
control  cryptography.13 

Cryptography  and  related  federal  policies  (e.g., 
regarding  export  controls  and  standards  develop¬ 
ment)  were  a  major  focus  of  the  1994  OTA  re¬ 
port.14  That  focus  was  due  in  part  from  the 
widespread  attention  being  given  the  so-called 
Clipper  chip  and  the  escrowed-encryption  initia¬ 
tive  announced  by  the  Clinton  Administration  in 
1993.  Escrowed  encryption,  or  key-escrow  en¬ 
cryption,  refers  to  an  encryption  method  where  the 
functional  equivalent  of  a  “spare  key”  must  be  de¬ 
posited  with  a  third  party.  The  rationale  for  key- 
escrow  encryption  is  to  ensure  government  access 
to  decryption  keys  when  encrypted  messages  are 
encountered  in  the  course  of  lawful  electronic  sur¬ 
veillance  (see  box  2-3  on  page  54).  The  Escrowed 
Encryption  Standard  (EES),  promulgated  as  a  fed- 


9  Figures  2- 1  and  2-2  on  pages  50  and  5 1  illustrate  two  common  forms  of  encryption:  secret-key  (or  symmetric)  encryption  and  public-key 
(or  asymmetric)  encryption.  Note  that  key  management — the  generation  of  encryption  and  decryption  keys,  as  well  as  their  storage,  distribu¬ 
tion,  cataloging,  and  eventual  destruction — is  crucial  for  the  overall  security  of  any  encryption  system. 

10  OTA,  op.  cit.,  footnote  5,  pp.  69-77.  See  Peter  H.  Lewis,  “Accord  Is  Reached  on  a  Common  Security  System  for  the  Internet,”  The  New 
York  Times,  Apr.  11,  1995,  p.  D5. 

1 1  OTA,  ibid. ,  pp.  96- 1 1 0.  For  example,  digital  signatures  can  be  used  to  create  compact  “copyright  tokens”  for  use  in  registries;  encryption 
could  be  used  to  create  personalized  “copyright  envelopes”  for  direct  electronic  delivery  of  material  to  customers.  See  also  Working  Group  on 
Intellectual  Property  Rights,  IITF,  “Intellectual  Property  and  the  National  Information  Infrastructure  (Green  Paper)  ”  July  1994,  pp.  139-140. 

>2  OTA,  ibid.,  pp.  11-13,  150-160. 

13  Ibid.,  pp.  115-123,  128-132,  154-160. 

14  Ibid.,  pp.  8-18  and  chapter  4. 
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eral  information  processing  standard  (FIPS)  in 
1994,  is  intended  for  use  in  encrypting  unclassi¬ 
fied  voice,  fax,  or  data  communicated  in  a  tele¬ 
phone  system.15  At  present,  all  the  Clipper  chip 
(i.e.,  EES)  “spare  keys”  are  held  within  the  execu¬ 
tive  branch. 

I  Government  Efforts 
To  Control  Cryptography 

In  its  activities  as  a  developer,  user,  and  regulator 
of  safeguard  technologies,  the  federal  government 
faces  a  fundamental  tension  between  two  policy 
objectives,  each  of  which  is  important:  1)  fos¬ 
tering  the  development  and  widespread  use  of 
cost-effective  information  safeguards;  and  2)  con¬ 
trolling  the  proliferation  of  safeguard  technolo¬ 
gies  that  can  impair  U.S.  signals-intelligence  and 
law  enforcement  capabilities.  Cryptography  is  at 
the  heart  of  this  tension.  Export  controls  and  the 
federal  standards  process  (i.e.,  the  development 
and  promulgation  of  federal  information  process¬ 
ing  standards,  or  FIPS)  are  two  mechanisms  the 
government  can  use  to  control  cryptography.16 

Policy  debate  over  cryptography  used  to  be  as 
arcane  as  the  technology  itself.  Even  5  or  10  years 
ago,  few  people  saw  a  link  between  government 
decisions  about  cryptography  and  their  daily 
lives.  However,  as  the  information  and  commu¬ 
nications  technologies  used  in  daily  life  have 
changed,  concern  over  the  implications  of  policies 
traditionally  dominated  by  national  security  ob¬ 
jectives  has  grown  dramatically. 


Previously,  control  of  the  availability  and  use 
of  cryptography  was  presented  as  a  national  secu¬ 
rity  issue  focused  outward,  with  the  intention  of 
maintaining  a  U.S.  technological  lead  over  other 
countries  and  preventing  encryption  devices  from 
falling  into  the  “wrong  hands”  overseas.  More 
widespread  foreign  use — including  use  of  strong 
encryption  by  terrorists  and  developing  coun¬ 
tries — makes  U.S.  signals  intelligence  more  diffi¬ 
cult. 

Now,  with  an  increasing  policy  focus  on  do¬ 
mestic  crime  and  terrorism,  the  availability  and 
use  of  cryptography  has  also  come  into  promi¬ 
nence  as  a  domestic-security,  law  enforcement  is¬ 
sue.  17  Within  the  United  States,  strong  encryption 
is  increasingly  portrayed  as  a  threat  to  domestic 
security  (public  safety)  and  a  barrier  to  law  en¬ 
forcement  if  it  is  readily  available  for  use  by  ter¬ 
rorists  or  criminals: 

. . .  Powerful  encryption  threatens  to  make 
worthless  the  access  assured  by  the  new  digital  law 
[i.e.,  the  Communications  Assistance  for  Law  En¬ 
forcement  Act].18 

Thus,  export  controls,  intended  to  restrict  the  in¬ 
ternational  availability  of  U.S.  cryptography 
technology  and  products,  are  now  being  joined 
with  domestic  cryptography  initiatives,  like  key- 
escrow  encryption,  that  are  intended  to  preserve 
U.S.  law  enforcement  and  signals-intelligence  ca¬ 
pabilities. 

Standards-development  and  export-control  is¬ 
sues  underlie  a  long  history  of  concern  over  lead- 


1 5  The  EES  is  implemented  in  hardware  containing  the  Clipper  chip.  The  EES  (FIPS- 1 85)  specifies  use  of  a  classified,  symmetric  encryption 
algorithm,  called  Skipjack,  which  was  developed  by  the  National  Security  Agency.  The  Capstone  chip  implements  the  Skipjack  algorithm  for 
use  in  computer  network  applications.  The  Defense  Department’s  FORTEZZA  card  (a  PCMCIA  card  formerly  called  TESSERA )  contains  the 
Capstone  chip. 

16  For  more  detail,  see  OTA,  op.  cit.,  footnote  5,  chapters  1  and  4  and  appendix  C.  Other  means  of  control  have  historically  included  national 
security  classification  and  patent-secrecy  orders  (see  ibid.,  p.  128  and  footnote  33). 

17  There  is  also  growing  organizational  recognition  of  potentials  for  misuse  of  encryption,  such  as  by  disgruntled  employees  as  a  means  to 
sabotage  an  employer’s  databases.  Thus,  some  “commercial  key-escrow”  or  “data  recovery”  facilities  are  being  developed  in  the  private  sector 
(see  discussion  below  and  in  ch.  4). 

18  Louis  J.  Freeh,  Director,  Federal  Bureau  of  Investigation,  testimony  before  the  U.S.  Senate,  Committee  on  the  Judiciary,  Feb.  14,  1995, 
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ership  and  responsibility  (i.e.,  “who  should  be  in 
charge?”  and  “who  is  in  charge?”)  for  the  secu¬ 
rity  of  unclassified  information  government- 
wide.19  Most  recently,  these  concerns  have  been 
revitalized  by  proposals  presented  by  the  Clinton 
Administration’s  Security  Policy  Board  staff20  to 
centralize  information-security  authorities  under 
joint  control  of  the  Office  of  Management  and 
Budget  (OMB)  and  Defense  Department  (see  dis¬ 
cussion  below  and  in  chapter  4). 

Other  manifestations  of  these  concerns  can  be 
found  in  the  history  of  the  Computer  Security  Act 
of  1987  (see  below  and  appendix  B)  and  in  more 
recent  developments,  such  as  public  reactions  to 
the  Clinton  Administration’s  key-escrow  encryp¬ 
tion  initiative  and  the  controversial  issuances  of 
the  Escrowed  Encryption  Standard21  and  Digital 
Signature  Standard  (DSS)22  as  federal  informa¬ 
tion  processing  standards.  Another  important 
manifestation  of  these  concerns  is  the  controversy 
over  the  present  U.S.  export  control  regime, 
which  includes  commercial  products  with  capa¬ 
bilities  for  strong  encryption,  including  mass- 
market  software,  on  the  Munitions  List,  under 
State  Department  controls  (see  below  and  appen¬ 
dix  C). 

I  Federal  Information 
Processing  Standards 

The  1994  OTA  report  concluded  that  two  recent 
federal  information  processing  standards  based 
on  cryptography  are  part  of  a  long-term  control 
strategy  intended  to  retard  the  general,  uncon¬ 
trolled  availability  of  strong  encryption  within  the 


United  States,  for  reasons  of  national  security  and 
law  enforcement.23  OTA  viewed  the  Escrowed 
Encryption  Standard  and  the  Digital  Signature 
Standard  as  complements  in  this  overall  control 
strategy,  intended  to  discourage  future  develop¬ 
ment  and  use  of  encryption  without  built-in  law 
enforcement  access,  in  favor  of  key-escrowed  en¬ 
cryption  and  related  encryption  technologies.  If 
the  EES  and/or  other  key-escrow  encryption  stan¬ 
dards  (e.g.,  for  use  in  computer  networks)  become 
widely  used  (or,  at  least,  enjoy  a  large,  guaranteed 
government  market),  this  could  ultimately  reduce 
the  variety  of  alternative  cryptography  products 
through  market  dominance  that  makes  alterna¬ 
tives  more  scarce  or  more  costly. 

The  Escrowed  Encryption  Standard  is  a  federal 
information  processing  standard  that  uses  a  classi¬ 
fied  algorithm,  called  “Skipjack,”  developed  by 
the  National  Security  Agency  (NSA).  It  was  pro¬ 
mulgated  as  a  voluntary  federal  information  proc¬ 
essing  standard.  The  Commerce  Department’s 
announcement  of  the  EES  noted  that  the  standard 
does  not  mandate  the  use  of  escrowed-encryption 
devices  by  government  agencies  or  the  private 
sector;  rather,  the  standard  provides  a  mechanism 
for  agencies  to  use  key-escrow  encryption  without 
having  to  waive  the  requirements  of  another,  ex¬ 
tant  federal  encryption  standard  for  unclassified 
information,  the  Data  Encryption  Standard 
(DES).24 

The  secret  encryption/decryption  key  for  Skip¬ 
jack  is  80  bits  long.  A  key-escrowing  scheme  is 
built  in  to  ensure  “lawfully  authorized”  electronic 
surveillance.25  The  algorithm  is  classified  and  is 


19  OTA,  op.  cit.,  footnote  5,  pp.  8-20  and  chapter  4. 

20  U.S.  Security  Policy  Board  Staff,  “Creating  a  New  Order  in  U.S.  Security  Policy,”  Nov.  21,  1994,  pp.  II-III,  14-18. 

21  See  box  2-3  in  chapter  2  of  this  background  paper  and  OTA,  op.  cit.,  footnote  5,  chapter  4. 

22  See  box  2-2  in  chapter  2  of  this  background  paper  and  OTA,  ibid.,  appendix  C. 

23  See  OTA,  op.  cit.,  footnote  5,  chapter  4. 

24  See  Federal  Register ,  vol.  59,  Feb.  9,  1994,  pp.  5997-6005  (“Approval  of  Federal  Information  Processing  Standards  Publication  185, 
Escrowed  Encryption  Standard  (EES)”),  especially  p.  5998.  Note  however,  that  the  DES  is  approved  for  encryption  of  unclassified  data  com¬ 
munications  and  files,  while  the  EES  is  only  a  standard  for  telephone  communications  at  this  time. 

25  Federal  Register ,  op.  cit.,  footnote  22,  p.  6003. 
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intended  to  be  implemented  only  in  tamper-resis¬ 
tant,  hardware  modules.26  This  approach  makes 
the  confidentiality  function  of  the  Skipjack  en¬ 
cryption  algorithm  available  in  a  controlled  fash¬ 
ion,  without  disclosing  the  algorithm’s  design 
principles  or  thereby  increasing  users’  abilities  to 
employ  cryptographic  principles.  One  of  the  rea¬ 
sons  stated  for  specifying  a  classified,  rather  than 
published,  encryption  algorithm  in  the  EES  is  to 
prevent  independent  implementation  of  Skipjack 
without  the  law  enforcement  access  features. 

The  EES  is  intended  for  use  in  encrypting  un¬ 
classified  voice,  fax,  and  computer  information 
communicated  over  a  telephone  system.  The 
Skipjack  algorithm  can  also  be  implemented  for 
data  encryption  in  computer  networks;  the  De¬ 
fense  Department  is  using  it  in  the  Defense  Mes¬ 
sage  System.  At  this  writing,  however,  there  is  no 
FIPS  specifying  use  of  Skipjack  as  a  standard  al¬ 
gorithm  for  data  communications  or  file  encryp¬ 
tion.  Given  that  the  Skipjack  algorithm  was 
selected  as  a  standard  for  telephony,  it  is  possible 
that  an  implementation  of  Skipjack  (or  some  other 
form  of  key-escrow  encryption)  will  be  selected  as 
a  FIPS  to  replace  the  DES  for  computer  commu¬ 
nications  and/or  file  encryption.  An  alternative 
successor  to  the  DES  that  is  favored  by  nongov¬ 
ernmental  users  and  experts  is  a  variant  of  DES 
called  triple-encryption  DES.  There  is,  however, 
no  FIPS  for  triple-encryption  DES. 

Unlike  the  Skipjack  algorithm,  the  algorithm  in 
the  federal  Digital  Signature  Standard  has  been 
published.27  The  public-key  algorithm  specified 
in  the  DSS  uses  a  private  key  in  signature  genera¬ 


tion,  and  a  corresponding  public  key  for  signature 
verification  (see  box  2-2).  However,  the  DSS 
technique  was  chosen  so  that  public-key  encryp¬ 
tion  functions  would  not  be  available  to  users.28 
This  is  significant  because  public-key  encryption 
is  extremely  useful  for  key  management  and 
could,  therefore,  contribute  to  the  spread  and  use 
of  nonescrowed  encryption.29  While  other  means 
of  exchanging  electronic  keys  are  possible,30  none 
is  so  mature  as  public-key  technology.  In  contrast 
to  the  technique  chosen  for  the  DSS,  the  technique 
used  in  the  most  popular  commercial  digital  sig¬ 
nature  system  (based  on  the  Rivest-Shamir-Adle- 
man,  or  RSA,  algorithm)  can  also  encrypt. 
Therefore,  the  RSA  techniques  can  be  used  for  se¬ 
cure  key  exchange  (i.e.,  exchange  of  “secret” 
keys,  such  as  those  used  with  the  DES),  as  well  as 
for  signatures.  At  present,  there  is  no  FIPS  for  key 
exchange. 

I  Federal  Standards  and  the 
Computer  Security  Act  of  1987 

The  Computer  Security  Act  of  1987  (Public  Law 
100-235)  is  fundamental  to  development  of  feder¬ 
al  standards  for  safeguarding  unclassified  in¬ 
formation,  to  balancing  national  security  and 
other  objectives  in  implementing  security  and  pri¬ 
vacy  policies  within  the  federal  government,  and 
to  other  issues  concerning  government  control  of 
cryptography.  Implementation  of  the  Computer 
Security  Act  has  been  controversial,  especially  re¬ 
garding  the  respective  roles  of  the  National  Insti¬ 
tute  of  Standards  and  Technology  (NIST)  and 


26  Federal  Register ,  ibid.,  pp.  5997-6005. 

27  See  appendix  C  of  OTA,  op.  cit.,  footnote  5,  for  a  history  of  the  DSS. 

28  According  to  F.  Lynn  McNulty,  NIST  Associate  Director  for  Computer  Security,  the  rationale  for  adopting  the  technique  used  in  DSS  was 
that,  “We  wanted  a  technology  that  did  signatures— and  nothing  else— very  well.”  (Response  to  a  question  from  Chairman  Rick  Boucher  in 
testimony  before  the  Subcommittee  on  Science  of  the  House  Committee  on  Science,  Space,  and  Technology,  Mar.  22,  1994.) 

29  Public-key  encryption  can  be  used  for  confidentiality  and,  thereby,  for  secure  key  exchange.  Thus,  public-key  encryption  can  facilitate 
the  use  of  symmetric  encryption  methods  like  the  DES  or  triple  DES.  See  figure  2-3. 

30  See,  e.g.,  Tom  Leighton,  Department  of  Mathematics,  Massachusetts  Institute  of  Technology  and  Silvio  Micali,  MIT  Laboratory  for 
Computer  Science,  “Secret-Key  Agreement  Without  Public-Key  Cryptography  (Extended  Abstract),”  obtained  from  S.  Micali,  1993. 
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NSA  in  standards  development  and  the  chronic 
shortage  of  resources  for  NIST’s  computer  securi¬ 
ty  program  to  fulfill  its  responsibilities  under  the 
act  (see  detailed  discussion  in  chapter  4  of  the 
1994  OTA  report).31 

The  Computer  Security  Act  of  1987  was  a  leg¬ 
islative  response  to  overlapping  responsibilities 
for  computer  security  among  several  federal  agen¬ 
cies,  heightened  awareness  of  computer  security 
issues,  and  concern  over  how  best  to  control  in¬ 
formation  in  computerized  or  networked  form. 
The  act  established  a  federal  government  com¬ 
puter-security  program  that  would  protect  all  un¬ 
classified,  sensitive  information  in  federal 
government  computer  systems  and  would  devel¬ 
op  standards  and  guidelines  to  facilitate  such 
protection.  The  act  also  established  a  Computer 
System  Security  and  Privacy  Advisory  Board 
(CSSPAB).  The  board,  appointed  by  the  Secretary 
of  Commerce,  is  charged  with  identifying  emerg¬ 
ing  safeguard  issues  relative  to  computer  systems 
security  and  privacy,  advising  the  former  National 
Bureau  of  Standards  (now  NIST)  and  the  Secre¬ 
tary  of  Commerce  on  security  and  privacy  issues 
pertaining  to  federal  computer  systems.  The 
CSSPAB  reports  its  findings  to  the  Secretary  of 
Commerce,  the  Director  of  OMB,  the  Director  of 
NSA,  and  to  the  “appropriate  committees  of  the 
Congress.”  Additionally,  the  act  required  federal 
agencies  to  identify  computer  systems  containing 
sensitive  information,  to  develop  security  plans 
for  identified  systems,  and  to  provide  periodic 
training  in  computer  security  for  all  federal  em¬ 
ployees  and  contractors  who  manage,  use,  or  oper¬ 
ate  federal  computer  systems.  Appendix  B,  drawn 
from  the  1994  OTA  report,  provides  more  back¬ 


ground  on  the  purpose  and  implementation  of  the 
Computer  Security  Act  and  on  the  FIPS. 

The  Computer  Security  Act  assigned  responsi¬ 
bility  for  developing  government-wide,  comput¬ 
er-system  security  standards  (e.g.,  the  FIPS)  and 
security  guidelines  and  security-training  pro¬ 
grams  to  the  National  Bureau  of  Standards.  Ac¬ 
cording  to  its  responsibilities  under  the  act,  NIST 
recommends  federal  information  processing  stan¬ 
dards  and  guidelines  to  the  Secretary  of  Com¬ 
merce  for  approval  (and  promulgation,  if 
approved).  These  FIPS  do  not  apply  to  classified 
or  “Warner  Amendment”  systems.32  NIST  can 
draw  on  the  technical  expertise  of  the  National  Se¬ 
curity  Agency  in  carrying  out  its  responsibilities, 
but  NSA’s  role  according  to  the  Computer  Securi¬ 
ty  Act,  is  an  advisory,  rather  than  leadership,  one. 

I  Federal  Standards  and  the  Marketplace 

As  the  1994  OTA  report  noted,  not  all  government 
attempts  at  influencing  the  marketplace  through 
the  FIPS  and  procurement  polices  are  successful. 
However,  the  FIPS  usually  do  influence  the 
technologies  used  by  federal  agencies  and  provide 
a  basis  for  interoperability,  thus  creating  a  large 
and  stable  “target  market”  for  safeguard  vendors. 
If  the  attributes  of  the  standard  technology  are  also 
applicable  to  the  private  sector  and  the  standard 
has  wide  appeal,  an  even  larger  but  still  relatively 
stable  market  should  result.  The  technological  sta¬ 
bility  means  that  firms  compete  less  in  terms  of 
the  attributes  of  the  fundamental  technology  and 
more  in  terms  of  cost,  ease  of  use,  and  so  forth. 
Therefore,  firms  need  to  invest  less  in  research  and 
development  (especially  risky  for  a  complex 


31  OTA,  op.  cit.,  footnote  5  and  chapter  4  and  appendix  B.  NIST’s  FY  1995  computer-security  budget  was  on  the  order  of  $6.5  million,  with 
$4.5  million  of  this  coming  from  appropriated  funds  for  “core”  activities  and  the  remainder  from  “reimbursable”  funds  from  other  agencies, 
mainly  the  Defense  Department. 

32  The  Warner  Amendment  (Public  Law  97-86)  excluded  certain  types  of  military  and  intelligence  “automatic  data  processing  equipment” 
procurements  from  the  requirements  of  section  111  of  the  Federal  Property  and  Administrative  Services  Act  of  1949  (40  U.S.C.  795).  Public 
Law  100-235  pertains  to  federal  computer  systems  that  come  under  section  111  of  the  Federal  Property  and  Administrative  Services  Act  of 
1949. 
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technology  like  cryptography)  and  in  convincing 
potential  customers  of  product  quality.  This  can 
result  in  higher  profits  for  producers,  even  in  the 
long  run,  and  in  increased  availability  and  use  of 
safeguards  based  on  the  standard. 

In  the  1970s,  promulgation  of  the  Data  Encryp¬ 
tion  Standard  as  a  stable  and  certified  technolo¬ 
gy — at  a  time  when  the  commercial  market  for 
cryptography-based  safeguards  for  unclassified 
information  was  just  emerging — stimulated  sup¬ 
ply  and  demand.  Although  the  choice  of  the  algo¬ 
rithm  was  originally  controversial  due  to  concerns 
over  NS  A’ s  involvement,  the  DES  gained  wide  ac¬ 
ceptance  and  has  been  the  basis  for  several  indus¬ 
try  and  international  standards,  in  large  part 
because  it  was  a  published  standard  that  could  be 
freely  evaluated  and  implemented.  The  process  by 
which  the  DES  was  developed  and  evaluated  also 
stimulated  private  sector  interest  in  cryptographic 
research,  ultimately  increasing  the  variety  of  com¬ 
mercial  safeguard  technologies.  Although  domes¬ 
tic  products  implementing  the  DES  are  subject  to 
U.S.  export  controls,  DES-based  technology  is 
available  overseas. 

The  1 994  OTA  report  regarded  the  introduction 
of  an  incompatible  new  federal  standard — for  ex¬ 
ample,  the  Escrowed  Encryption  Standard — as 
destabilizing.  At  present,  the  EES  and  other  im¬ 
plementations  of  Skipjack  (e.g.,  for  data  commu¬ 
nications)  have  gained  little  favor  in  the  private 
sector.  Features  such  as  the  government  key-es¬ 
crow  agencies,  classified  algorithm,  and  hard- 
ware-only  implementation  all  contribute  to  the 
lack  of  appeal.  But,  if  key-escrow  encryption 
technologies  ultimately  do  manage  to  gain  wide 
appeal  in  the  marketplace,  they  might  be  able  to 
“crowd  out”  safeguards  that  are  based  upon  other 
cryptographic  techniques  and/or  do  not  support 
key  escrowing.33 

The  1994  OTA  report  noted  that  this  type  of 
market  distortion,  intended  to  stem  the  supply  of 


alternative  products,  may  be  a  long-term  objective 
of  the  key-escrow  encryption  initiative.  In  the 
long  term,  a  loss  of  technological  variety  is  signif¬ 
icant  to  private  sector  cryptography,  because  more 
diverse  research  and  development  efforts  tend  to 
increase  the  overall  pace  of  technological  ad¬ 
vance.  In  the  near  term,  technological  uncertainty 
may  delay  widespread  investments  in  any  new 
safeguard,  as  users  wait  to  see  which  technology 
prevails.  The  costs  of  additional  uncertainties  and 
delays  due  to  control  interventions  are  ultimately 
borne  by  the  private  sector  and  the  public. 

Other  government  policies  can  also  raise  costs, 
delay  adoption,  or  reduce  variety.  For  example, 
export  controls  have  the  effect  of  segmenting  do¬ 
mestic  and  export  encryption  markets.  This 
creates  additional  disincentives  to  invest  in  the  de¬ 
velopment — or  use — of  robust,  but  nonexport¬ 
able,  products  with  integrated  strong  encryption 
(see  discussion  below). 

I  Export  Controls 

Another  locus  of  concern  is  export  controls  on 
cryptography.34  The  United  States  has  two  regula¬ 
tory  regimes  for  exports,  depending  on  whether 
the  item  to  be  exported  is  military  in  nature,  or  is 
“dual-use,”  having  both  civilian  and  military  uses 
(see  appendix  C).  These  regimes  are  administered 
by  the  State  Department  and  the  Commerce  De¬ 
partment,  respectively.  Both  regimes  provide  ex¬ 
port  controls  on  selected  goods  or  technologies  for 
reasons  of  national  security  or  foreign  policy.  Li¬ 
censes  are  required  to  export  products,  services,  or 
scientific  and  technical  data  originating  in  the 
United  States,  or  to  re-export  these  from  another 
country.  Licensing  requirements  vary  according 
to  the  nature  of  the  item  to  be  exported,  the  end 
use,  the  end  user,  and,  in  some  cases,  the  intended 
destination.  For  many  items  under  Commerce  ju¬ 
risdiction,  no  specific  approval  is  required  and  a 


33  OTA,  op.  cit.,  footnote  5,  pp.  128-132.  A  large,  stable,  lucrative  federal  market  could  divert  vendors  from  producing  alternative,  riskier 
products;  product  availability  could  draw  private  sector  customers. 

34  For  more  detail,  see  ibid,  and  chapters  1  and  4. 
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“general  license”  applies  (e.g.,  when  the  item  in 
question  is  not  military  or  dual-use  and/or  is  wide¬ 
ly  available  from  foreign  sources).  In  other  cases, 
an  export  license  must  be  applied  for  from  either 
the  State  Department  or  the  Commerce  Depart¬ 
ment,  depending  on  the  nature  of  the  item.  In 
general,  the  State  Department’s  licensing  require¬ 
ments  are  more  stringent  and  broader  in  scope.35 

Software  and  hardware  for  robust,  user-con- 
trolled  encryption  are  under  State  Department 
control,  unless  State  grants  jurisdiction  to  Com¬ 
merce.  This  has  become  increasingly  controver¬ 
sial,  especially  for  the  information  technology  and 
software  industries.36  The  impact  of  export  con¬ 
trols  on  the  overall  cost  and  availability  of  safe¬ 
guards  is  especially  troublesome  to  business  and 
industry  at  a  time  when  U.S.  high-technology 
firms  find  themselves  as  targets  for  sophisticated 
foreign-intelligence  attacks  and  thus  have  urgent 
need  for  sophisticated  safeguards  that  can  be  used 
in  operations  worldwide,  as  well  as  for  secure 
communications  with  overseas  business  partners, 


suppliers,  and  customers.37  Software  producers 
assert  that,  although  other  countries  do  have  ex¬ 
port  and/or  import  controls  on  cryptography,  sev¬ 
eral  countries  have  more  relaxed  export  controls 
on  cryptography  than  does  the  United  States.38 

On  the  other  hand,  U.S.  export  controls  may 
have  substantially  slowed  the  proliferation  of 
cryptography  to  foreign  adversaries  over  the 
years.  Unfortunately,  there  is  little  public  explana¬ 
tion  regarding  the  degree  of  success  of  these  ex¬ 
port  controls  and  the  necessity  for  maintaining 
strict  controls  on  strong  encryption  in  the  face  of 
foreign  supply39  and  networks  like  the  Internet 
that  seamlessly  cross  national  boundaries.40 

Appendix  C  of  this  background  paper,  drawn 
from  the  1994  OTA  report,  provides  more  back¬ 
ground  on  export  controls  on  cryptography.  In 
September  1994,  after  the  OTA  report  had  gone  to 
press,  the  State  Department  announced  an  amend¬ 
ment  to  the  regulations  implementing  section  38 
of  the  Arms  Export  Control  Act.  The  new  rule  im- 


35  Ibid.,  pp.  150-154. 

36  To  ease  some  of  these  burdens,  the  State  Department  announced  new  licensing  procedures  on  Feb.  4, 1994.  These  changes  were  expected 
to  include  to  include  license  reform  measures  for  expedited  distribution  (to  reduce  the  need  to  obtain  individual  licenses  for  each  end  user),  rapid 
review  of  export  license  applications,  personal-use  exemptions  for  U.S.  citizens  temporarily  taking  encryption  products  abroad  for  their  own 
use,  and  special  licensing  arrangements  allowing  export  of  key-escrow  encryption  products  (e.g.,  EES  products)  to  most  end  users.  At  this  writ¬ 
ing,  expedited-distribution  reforms  were  in  place  {Federal  Register ,  Sept.  2,  1994,  pp.  45621-45623),  but  personal-use  exemptions  were  still 
under  contention  (Karen  Hopkinson,  Office  of  Defense  Trade  Controls,  personal  communication,  Mar.  8,  1995). 

37  See,  e.g.,  U.S.  Congress,  House  of  Representatives,  Subcommittee  on  Economic  and  Commercial  Law,  Committee  on  the  Judiciary,  The 
Threat  of  Foreign  Economic  Espionage  to  U.S.  Corporations ,  hearings,  102d  Congress,  2dsess.,  Apr.  29  and  May  7, 1992,  Serial  No.  65  (Wash¬ 
ington,  DC:  U.S.  Government  Printing  Office,  1992).  See  also  discussion  of  business  needs  and  export  controls  in  chapter  3  of  this  background 
paper. 

38  OTA,  op.  cit.,  footnote  5,  pp.  154-160.  Some  other  countries  do  have  stringent  export  and/or  import  restrictions. 

39  For  example,  the  Software  Publishers  Association  has  studied  the  worldwide  availability  of  encryption  products  and,  as  of  October  1994, 
found  170  software  products  (72  foreign,  98  U.S.-made)  and  237  hardware  products  (85  foreign,  152  U.S.-made)  implementing  the  DES  algo¬ 
rithm  for  encryption.  (Trusted  Information  Systems,  Inc.  and  Software  Publishers  Association,  Encryption  Products  Database  Statistics ,  Octo¬ 
ber  1994.)  Also  see  OTA,  op.  cit.,  footnote  5,  pp.  156-160. 

40  For  a  discussion  of  export  controls  and  network  dissemination  of  encryption  technology,  see  Simson  Garfinkle,  PGP:  Pretty  Good  Priva¬ 
cy  (Sebastopol,  CA;  O’Reilly  and  Assoc.,  1995).  PGP  is  an  encryption  program  developed  by  Phil  Zimmerman.  Variants  of  the  PGP  software 
(some  of  which  are  said  to  infringe  the  RSA  patent  in  the  United  States)  have  spread  worldwide  over  the  Internet.  Zimmerman  has  been  under 
grand  jury  investigation  since  1993  for  allegedly  breaking  the  munitions  export-control  laws  by  permitting  the  software  to  be  placed  on  an 
Internet-accessible  bulletin  board  in  the  United  States  in  1991 .  (See  Vic  Sussman,  “Lost  in  Kafka  Territory,”  U.S.  News  and  World  Report ,  Apr. 
3,  1995,  pp.  30-31.) 
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plements  one  of  the  reforms  applicable  to  encryp¬ 
tion  products  that  were  announced  on  February  4, 
1994,  by  the  State  Department.41  Other  an¬ 
nounced  reforms,  still  to  be  implemented,  include 
special  licensing  procedures  allowing  export  of 
key-escrow  encryption  products  to  “most  end  us¬ 
ers.”42  The  ability  to  export  strong,  key-escrow 
encryption  products  would  presumably  increase 
escrowed-encryption  products’  appeal  to  private- 
sector  safeguard  developers  and  users. 

In  the  103d  Congress,  legislation  intended  to 
streamline  export  controls  and  ease  restrictions  on 
mass-market  computer  software,  hardware,  and 
technology,  including  certain  encryption  soft¬ 
ware,  was  introduced  by  Representative  Maria 
Cantwell  (H.R.  3627)  and  Senator  Patty  Murray 
(S.  1846).  In  considering  the  Omnibus  Export  Ad¬ 
ministration  Act  of  1994  (H.R.  3937),  the  House 
Committee  on  Foreign  Affairs  reported  a  version 
of  the  bill  in  which  most  computer  software  (in¬ 
cluding  software  with  encryption  capabilities) 
was  under  Commerce  Department  controls  and  in 
which  export  restrictions  for  mass-market  soft¬ 
ware  with  encryption  were  eased.  In  its  report,  the 
House  Permanent  Select  Committee  on  Intelli¬ 
gence  struck  out  this  portion  of  the  bill  and  re¬ 
placed  it  with  a  new  section  calling  for  the 
President  to  report  to  Congress  within  150  days  of 
enactment,  regarding  the  current  and  future  in¬ 
ternational  market  for  software  with  encryption 
and  the  economic  impact  of  U.S.  export  controls 
on  the  U.S.  computer  software  industry  43 


At  the  end  of  the  103d  Congress,  omnibus  ex¬ 
port  administration  legislation  had  not  been  en¬ 
acted.  Both  the  House  and  Senate  bills  contained 
language  calling  for  the  Clinton  Administration  to 
conduct  comprehensive  studies  on  the  interna¬ 
tional  market  and  availability  of  encryption 
technologies  and  the  economic  effects  of  U.S.  ex¬ 
port  controls.  In  a  July  20,  1994,  letter  to  Repre¬ 
sentative  Cantwell,  Vice  President  Gore  had 
assured  her  that  the  “best  available  resources  of 
the  federal  government”  would  be  used  in  con¬ 
ducting  these  studies  and  that  the  Clinton  Admin¬ 
istration  would  “reassess  our  existing  export 
controls  based  on  the  results  of  these  studies.”44 

At  this  writing,  the  Commerce  Department  and 
NS  A  are  assessing  the  economic  impact  of  U.S. 
export  controls  on  cryptography  on  the  U.S.  com¬ 
puter  software  industry.45  As  part  of  the  study, 
NSA  is  determining  the  foreign  availability  of  en¬ 
cryption  products.  The  study  is  scheduled  to  be 
delivered  to  the  National  Security  Council  by  July 
1,  1995.  According  to  the  National  Security 
Council  (NSC),  it  is  anticipated  that  there  will  be 
both  classified  and  an  unclassified  sections  of  the 
study;  there  may  be  some  public  release  of  the  un¬ 
classified  material 46  In  addition,  an  ongoing  Na¬ 
tional  Research  Council  (NRC)  study  that  would 
support  a  broad  congressional  review  of  cryptog¬ 
raphy  (and  that  is  expected  to  address  export  con¬ 
trols)  is  due  to  be  completed  in  1996.47  At  this 


41  Department  of  State,  Bureau  of  Political-Military  Affairs,  22  CFR  parts  123  and  124,  Federal  Register,  vol.  59,  No.  170,  Sept.  2, 1994,  pp. 
45621-45623.  See  note36  above  andalso  ch.4of  the  1994  OTAreport.  Thereform  established  a  new  licensing  procedure  to  permit  U.S.  encryp¬ 
tion  manufacturers  to  make  multiple  shipments  of  some  encryption  items  directly  to  end  users  in  approved  countries,  without  obtaining  individ¬ 
ual  licenses  (see  appendix  C). 

42  Martha  Harris,  Deputy  Assistant  Secretary  for  Political-Military  Affairs,  U.S.  Department  of  State,  “Encryption-Export  Control  Re¬ 
form,”  statement,  Feb.  4,  1994.  See  OTA,  op.  cit.,  footnote  5,  pp.  159-160. 

43  A  study  of  this  type  (see  below)  is  expected  to  be  completed  in  mid- 1995. 

44  Vice  President  A1  Gore,  letter  to  Representative  Maria  Cantwell,  July  20,  1994.  See  OTA,  op.  cit.,  footnote  5,  pp.  11-13. 

45  Maurice  Cook,  Bureau  of  Export  Administration,  Department  of  Commerce,  personal  communication,  Mar.  7,  1995. 

46  Bill  Clements,  National  Security  Council,  personal  communication,  Mar.  21,  1995. 

47  For  information  about  the  NRC  study,  which  was  mandated  by  Public  Law  103-160,  contact  Herb  Lin,  National  Research  Council,  2101 
Constitution  Avenue,  NW,  Washington,  DC  20418  (crypto@nas.edu).  See  discussion  in  OTA,  op.  cit.,  footnote  5,  chapters  1  and  4. 
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writing,  the  NRC  study  committee  is  gathering 
public  input  on  cryptography  issues. 

In  the  104th  Congress,  Representative  Toby 
Roth  has  introduced  the  “Export  Administration 
Act  of  1995”  (H.R.  361).  This  bill  did  not  include 
any  specific  references  to  cryptography.  At  this 
writing,  it  is  not  clear  whether  or  when  the  conten¬ 
tious  issue  of  cryptography  export  controls  will 
become  part  of  legislative  deliberations. 

Alternatively,  the  Clinton  Administration 
could  ease  export  controls  on  cryptography  with¬ 
out  legislation.  As  was  noted  above,  being  able  to 
export  key-escrow  encryption  products  would 
presumably  make  escrowed-encryption  products 
more  attractive  to  commercial  developers  and  us¬ 
ers.  Therefore,  the  Clinton  Administration  could 
ease  export  requirements  for  products  with  inte¬ 
grated  key  escrowing  as  an  incentive  for  the  com¬ 
mercial  development  and  adoption  of  such 
products  (see  discussion  of  cryptography  initia¬ 
tives  below  and  in  chapter  4). 

OTA  WORKSHOP  FINDINGS 

At  the  request  of  the  Senate  Committee  on  Gov¬ 
ernmental  Affairs,  OTA  held  a  workshop  titled 
“Information  Security  and  Privacy  in  Network 
Environments:  What  Next?”  on  December  6, 
1994  as  part  of  its  follow-on  activities  after  the  re¬ 
lease  of  the  1994  report.  Workshop  participants 
came  from  the  business,  legal,  university,  and 
public-interest  communities.  One  workshop  ob¬ 
jective  was  to  gauge  participants’  overall  reac¬ 
tions  to  the  OTA  report  Information  Security  and 
Privacy  in  Network  Environments.  Another  was  to 
identify  related  topics  that  merited  attention  and 
that  OTA  had  not  already  addressed  (e.g.,  network 
reliability  and  survivability  or  “corporate”  pri¬ 
vacy — see  chapter  3).  A  third  objective  was  for 
participants  to  identifyas  specifically  as  possi- 
bleareas  ripe  for  congressional  action. 

The  general  areas  of  interest  were: 

1.  the  marketplace  for  information  safeguards 
and  factors  affecting  supply  and  demand; 

2.  information-security  “best  practices”  in  the 
private  sector,  including  training  and  imple¬ 


mentation,  and  their  applicability  to  govern¬ 
ment  information  security; 

3 .  the  impacts  of  federal  information-security  and 
policies  on  business  and  the  public;  and 

4.  desirable  congressional  actions  and  suggested 
time  frames  for  any  such  actions. 

Chapter  3  of  this  background  paper  highlights 
major  points  and  opinions  expressed  by  the  work¬ 
shop  participants.  It  is  important  to  note  that  the 
presentation  in  chapter  3  and  the  summary  below 
are  not  intended  to  represent  conclusions  reached 
by  the  participants;  moreover,  the  reader  should 
not  infer  any  general  consensus,  unless  consensus 
is  specifically  noted. 

Several  major  themes  emerged  from  the  discus¬ 
sion  regarding  export  controls  and  the  business 
environment,  federal  cryptography  policy,  and 
characteristics  of  information-security  “best  prac¬ 
tices”  that  are  germane  to  consideration  of  govern¬ 
ment  information  security.  These  have  particular 
significance,  especially  in  the  context  of  current 
developments,  for  congressional  consideration  of 
several  of  the  information-security  issues  and  op¬ 
tions  identified  in  the  1994  OTA  report.  These 
themes  include: 

The  mismatch  between  the  domestic  and  in¬ 
ternational  effects  of  current  U.S.  export  con¬ 
trols  on  cryptography  and  the  needs  of  business 
and  user  communities  in  an  international 
economy. 

The  need  for  reform  of  export  controls  was  the 
number  one  topic  at  the  workshop  and  perhaps  the 
only  area  of  universal  agreement.  Participants  ex¬ 
pressed  great  concern  that  the  current  controls  are 
impeding  companies’  implementation  of  good  se¬ 
curity  in  worldwide  operations  and  harming  U.S. 
firms’  competitiveness  in  the  international  mar¬ 
ketplace.  More  than  one  participant  considered 
that  what  is  really  at  stake  is  loss  of  U.S.  leader¬ 
ship  in  the  information  technology  industry.  As 
one  participant  put  it,  the  current  system  is  “a  mar¬ 
ket  intervention  by  the  government  with  unin¬ 
tended  bad  consequences  for  both  government 
and  the  private  sector.” 
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Several  participants  asserted  that  U.S.  export 
controls  have  failed  at  preventing  the  spread  of 
cryptography,  because  DES-  and  RSA-based  en¬ 
cryption,  among  others,  are  available  outside  of 
this  country.  These  considered  that  the  only  “suc¬ 
cess”  of  the  controls  has  been  to  prevent  major 
U.S.  software  companies  from  incorporating 
high-quality,  easy-to-use,  integrated  cryptogra¬ 
phy  in  their  products. 

The  intense  dissatisfaction  on  the  part  of  the 
private  sector  with  the  lack  of  openness  and 
progress  in  resolving  cryptography-policy 
issues. 

Participants  expressed  frustration  with  the  lack 
of  a  timely,  open,  and  productive  dialogue  be¬ 
tween  government  and  the  private  sector  on  cryp¬ 
tography  issues  and  the  lack  of  response  by 
government  to  what  dialogue  has  taken  place.48 
Many  stressed  the  need  for  a  genuine,  open  dia¬ 
logue  between  government  and  business,  with 
recognition  that  business  vitality  is  a  legitimate 
objective.  Participants  noted  the  need  for  Con¬ 
gress  to  broaden  the  policy  debate  about  cryptog¬ 
raphy,  with  more  public  visibility  and  more 
priority  given  to  business  needs  and  economic 
concerns.  In  the  export  control  arena.  Congress 
was  seen  as  having  an  important  role  in  getting 
government  and  the  private  sector  to  converge  on 
some  feasible  middle  ground  (legislation  would 
not  be  required,  if  export  regulations  were 
changed).  Leadership  and  timeliness  (“the  prob¬ 
lem  won’t  wait”)  were  viewed  as  priorities,  rather 
than  more  studies  and  delay. 

Many  felt  the  information-policy  branches  of 
the  government  are  unable  to  respond  adequately 
to  the  current  leadership  vacuum;  therefore,  they 
felt  that  government  should  either  establish  a 
more  effective  policy  system  and  open  a  construc¬ 
tive  dialogue  with  industry  or  leave  the  problem  to 
industry. 

The  lack  of  public  dialogue,  visibility,  and  ac¬ 
countability,  particularly  demonstrated  by  the 
manner  in  which  the  Clipper  chip  was  introduced 


and  the  EES  promulgated,  seemed  to  be  a  constant 
source  of  anger  for  both  industry  representatives 
and  public  interest  groups.  There  were  many  con¬ 
cerns  and  frustrations  about  the  role  of  the  Nation¬ 
al  Security  Agency.  Many  participants  suggested 
that  this  country  desperately  needs  a  new  vision  of 
“national  security”  that  incorporates  economic 
vitality.  They  consider  that  business  strength  is 
not  part  of  NSA’s  notion  of  “national  security,”  so 
it  is  not  part  of  their  mission.  As  one  participant 
put  it,  “saying  that  ‘we  all  have  to  be  losers’  on  na¬ 
tional  security  grounds  is  perverse  industrial 
policy.” 

The  mismatch  between  the  federal  standards 
process  for  cryptography-related  FIPS  and 
private  sector  needs  for  exportable,  cost-effec¬ 
tive  safeguards. 

As  noted  above,  many  participants  viewed  ex¬ 
port  controls  as  the  single  biggest  obstacle  to  es¬ 
tablishing  international  standards  for  information 
safeguards,  One  participant  also  noted  the  pecu¬ 
liarity  of  picking  a  national  standard  (e.g.,  a  FIPS 
like  the  DES)  and  then  trying  to  restrict  its  use  in¬ 
ternationally. 

The  question  of  the  availability  of  secure  prod¬ 
ucts  generated  some  disagreement  over  whether 
the  market  works  or,  at  least,  the  extent  to  which  it 
does  and  does  not  work.  There  was  consensus  that 
export  controls  and  other  government  policies  that 
segmented  market  demand  were  undesirable  in¬ 
terventions.  Though  the  federal  government  can 
use  its  purchasing  power  to  significantly  influence 
the  market,  most  participants  felt  that  this  sort  of 
market  intervention  would  not  be  beneficial  over¬ 
all. 

The  mismatch  between  the  intent  of  the  Com¬ 
puter  Security  Act  and  its  implementation. 

There  was  widespread  support  for  the  Comput¬ 
er  Security  Act  of  1987,  but  universal  frustration 
with  its  implementation.  NIST,  the  designated 
lead  agency  for  security  standards  and  guidelines, 
was  described  as  underfunded  and  extremely 


48  See  ibid.,  pp.  11-13,  150-160,  174-179. 


16 1  Issue  Update  on  Information  Security  and  Privacy  in  Network  Environments 


slow.  There  was  also  a  general  recognition  that 
people  had  been  complaining  about  NIST  for  a 
while,  but  nothing  has  happened  as  a  result  of 
these  complaints.  Some  participants  noted  the  im¬ 
portance  of  increased  oversight  of  the  Computer 
Security  Act  of  1987  (Public  Law  100-235),  as 
well  as  possible  redirection  of  NIST  activities 
(e.g.,  collecting  information  about  what  industry 
is  doing,  pointing  out  commonalities  and  how  to 
interoperate,  rather  than  picking  out  a  “standard”). 

According  to  some  participants,  the  govern¬ 
ment  should  get  “its  house  in  order”  in  the  civilian 
agencies  and  place  more  emphasis  on  unclassified 
information  security.  There  was  a  perceived  need 
for  timely  attention,  because  the  architecture  and 
policy  constructs  of  the  international  information 
infrastructure  are  being  developed  right  now,  but 
these  are  “being  left  to  the  technologists”  due  to 
lack  of  leadership. 

Several  felt  that  the  government  has  overem¬ 
phasized  cryptography,  to  the  exclusion  of  man¬ 
agement  and  problems  like  errors  and  dishonest 
employees  that  are  not  fully  addressed  by  a 
“technology”  focus.  Participants  considered  that 
the  real  issue  is  management ,  not  technology  slo- 
ganism.  According  to  participants,  existing  poli¬ 
cies  [e.g.,  the  previous  version  of  OMB  Circular 
A- 130,  Appendix  III]  attempt  to  mandate  cost- 
based  models,  but  the  implementation  is  ineffec¬ 
tive.  For  example,  after  the  Computer  Security 
Act,  NIST  should  have  been  in  a  position  to  help 
agencies,  but  this  never  happened  due  to  lack  of 
resources.  Civil  agencies  lack  resources,  then 
choose  to  invest  in  new  applications  rather  than 
spend  on  security.  This  is  understandable  when 
the  observation  that  “nothing  happens” — that  is, 
no  security  incidents  are  detected — is  an  indicator 
of  good  security.  Participants  observed  that,  if  in¬ 
spectors  general  of  government  agencies  are  per¬ 
ceived  as  neither  rewarding  or  punishing,  users 
get  mixed  signals  and  conclude  that  there  is  a  mis¬ 
match  between  security  postures  and  management 
commitment  to  security  implementation. 

The  distinction  between  security  policies  and 

guidelines  for  implementing  these  policies; 

and 


the  need  for  technological  flexibility  in  imple¬ 
menting  security  policies. 

Sound  security  policies  are  a  foundation  for 
good  security  practice.  Importantly,  these  are  not 
guidelines  for  implementation.  Rather,  they  are 
“minimalist”  directives  that  outline  what  must 
happen  to  maintain  information  security,  but  not 
how  it  must  be  achieved. 

One  of  the  most  important  things  about  these 
policies  is  that  they  are  consistent  across  the  entire 
company;  regardless  of  the  department,  informa¬ 
tion-security  policies  are  considered  universally 
applicable.  The  policies  have  to  be  designed  in  a 
broad  enough  fashion  to  ensure  that  all  company 
cultures  will  be  able  to  comply.  (Implementation 
of  these  polices  can  be  tailored  to  fit  specific  needs 
and  business  practices.)  Broad  policy  outlines  al¬ 
low  information  to  flow  freely  between  company 
divisions  without  increased  security  risk. 

The  workshop  discussion  noted  the  importance 
of  auditing  security  implementation  against 
policy,  not  against  implementation  guidelines. 
Good  security  policies  must  be  technology  neu¬ 
tral,  so  that  technology  upgrades  and  different 
equipment  in  different  divisions  would  not  affect 
implementation.  Ensuring  that  policies  are 
technology  neutral  helps  prevent  confusing  im¬ 
plementation  techniques  and  tools  (e.g.,  use  of  a 
particular  type  of  encryption  or  use  of  a  computer 
operating  system  with  a  certain  rating)  with  policy 
objectives,  and  discourages  “passive  risk  accep¬ 
tance”  like  mandating  use  of  a  particular  tech¬ 
nology.  This  also  allows  for  flexibility  and 
customization. 

Workshop  participants  noted  that,  although  the 
state  of  practice  in  setting  security  policy  often  has 
not  lived  up  to  the  ideals  discussed  above,  many 
companies  are  improving.  At  this  point  there  are 
several  road  blocks  frustrating  more  robust  securi¬ 
ty  for  information  and  information  systems.  A  pri¬ 
mary  road  block  is  cost.  Many  systems  are  not 
built  with  security  in  mind,  so  the  responsibility 
falls  on  the  end  user  and  retrofitting  a  system  with 
security  can  be  prohibitively  expensive. 
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The  need  for  line-management  accountability 
for,  and  commitment  to,  good  security,  as  op¬ 
posed  to  “handing  off"  security  to  technology 
( i.  e.,  hoping  that  a  “technological  fix  ”  will  be  a 
cure-all). 

The  workshop  discussion  emphasized  active 
risk  acceptance  by  management  and  sound  securi¬ 
ty  policies  as  key  elements  of  good  information- 
security  practice  in  the  private  sector.  The  concept 
of  management  responsibility  and  accountability 
as  integral  components  of  information  security, 
rather  than  just  “handing  off’  security  to  technolo¬ 
gy,  were  noted  as  very  important  by  several  partic¬ 
ipants.  There  was  general  agreement  that  direct 
support  by  top  management  and  upper-manage¬ 
ment  accountability  are  central  to  successful 
implementation  of  security  policies.  Many  partic¬ 
ipants  considered  it  vital  that  the  managers  under¬ 
stand  active  risk  acceptance  and  not  be  insulated 
from  risk. 

Most  security  managers  participating  in  the 
workshop  viewed  training  as  vital  to  any  success¬ 
ful  information-security  policy.  Lack  of  training 
leads  to  simple  errors  potentially  capable  of  de¬ 
feating  any  good  security  systemfor  example,  em¬ 
ployees  who  write  their  passwords  on  paper  and 
tape  it  to  their  computers.  Several  participants 
knew  of  companies  that  have  fallen  into  the 
technology  trap  and  have  designed  excellent  com¬ 
puter  security  systems  without  sufficiently  em¬ 
phasizing  training.  There  is  a  core  of  training 
material  that  is  technology  neutral  and  ubiquitous 
across  the  company.  The  necessity  for  impressing 
upon  employees  their  role  in  information  security 
was  seen  as  paramount. 


ISSUE  UPDATE 

Chapter  4  provides  an  update  on  executive-branch 
and  private  sector  cryptography  developments, 
business  perspectives  on  government  policies, 
congressional  consideration  of  privacy  issues,  and 
government-wide  guidance  on  information  secu¬ 
rity  in  the  federal  agencies.  The  last  section  of 
chapter  4  discusses  the  implications  of  these  de¬ 
velopments  for  congressional  consideration  of 
some  of  the  issues  and  options  identified  in  the 
1994  OTA  report. 

I  Government  Cryptography  Activities 

In  mid- 1994,  the  executive  branch  indicated  an 
openness  toward  exploring  alternative  forms  of 
key-escrow  encryption  (i.e.,  techniques  not  im¬ 
plementing  the  Skipjack  algorithm  specified  in 
the  Escrowed  Encryption  Standard  (EES)  for  use 
in  computer  and  video  networks.49  However, 
there  has  been  no  formal  commitment  to  eventual¬ 
ly  adopting  any  alternative  to  Skipjack  in  an  es¬ 
crowed-encryption  FIPS  for  computer  data.50 
Moreover,  there  has  been  no  commitment  to  con¬ 
sider  alternatives  to  the  EES  for  telephony. 

Furthermore,  there  has  been  no  backing  away 
from  the  underlying  Clinton  Administration  com¬ 
mitment  to  “escrowing”  encryption  keys.  With 
tightly  integrated,  or  “bound”  escrowing,  there  is 
mandatory  key  deposit.  In  the  future,  there  may  be 
some  choice  of  escrow  agencies  or  registries,  but 
at  present,  Clipper-  and  Capstone-chip  keys  are 
being  escrowed  within  the  Commerce  and  Trea¬ 
sury  Departments.51  The  Clinton  Administration 
has  not  indicated  an  openness  toward  optional  de- 


49  For  background,  see  appendix  D  of  this  background  paper  and  OTA,  op.  cit.,  footnote  5,  pp.  1 5- 1 6, 17 1  - 1 74.  The  Escrowed  Encryption 
Standard  is  described  in  box  2-3  of  this  paper. 

50  See  box  2-3.  The  Capstone  chip  refers  to  a  hardware  implementation  of  the  EES’s  Skipjack  algorithm,  but  for  data  communications. 
FORTEZZA  (formerly  TESSERA)  is  a  PCMCIA  card  implementing  Skipjack  for  data  encryption,  as  well  as  the  Digital  Signature  Standard  (see 
box  2-2)  and  key-exchange  functions. 

51  These  chips  implement  the  Skipjack  algorithm  for  the  EES  and  FORTEZZA  applications,  respectively. 
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posit  of  keys  with  registries,  which  OTA  referred 
as  “trusteeship”  in  the  1994  report  (to  distinguish 
it  from  the  Clinton  Administration’s  concept  of 
key  escrowing  being  required  as  an  integral  part  of 
escrowed-encryption  systems).52 

The  questions  of  whether  or  when  there  will  be 
key-escrow  encryption  federal  information  proc¬ 
essing  standards  for  unclassified  data  commu¬ 
nications  and/or  file  encryption  is  still  open.  There 
is  at  present  no  FIPS  specifying  use  of  Skipjack 
for  these  applications.  Implementation  of  key  es¬ 
crowing  or  trusteeship  for  large  databases  (i.e., 
encryption  for  file  storage,  as  opposed  to  commu¬ 
nications)  has  not  been  addressed  by  the  govern¬ 
ment.  However,  commercial  key  depositories  or 
data-recovery  centers  are  being  proposed  by  sev¬ 
eral  companies  (see  next  section  on  private  sector 
developments). 

Turning  from  encryption  to  digital  signatures, 
acceptance  and  use  of  the  new  FIPS  for  digital  sig¬ 
natures  is  progressing,  but  slowly.  As  the  1994  re¬ 
port  detailed  in  its  description  of  the  evolution  of 
the  Digital  Signature  Standard,  patent  problems 
complicated  the  development  and  promulgation 
of  the  standard.53  Patent-infringement  uncertain¬ 
ties  remain  for  the  DSS,  despite  the  government’s 
insistence  that  the  DSS  algorithm  does  not  in¬ 
fringe  any  valid  patents  and  its  offer  to  indemnify 
vendors  that  develop  certificate  authorities  for  a 
public-key  infrastructure.54 

Plans  to  implement  the  DSS  throughout  gov¬ 
ernment  are  complicated  by  the  relatively  broad 


private  sector  use  of  a  commercial  alternative,  the 
RSA  signature  system,  and  some  agencies’  desire 
to  use  the  RSA  system  instead  of,  or  alongside,  the 
DSS.  Cost,  as  well  as  interoperability  with  the  pri¬ 
vate  sector,  is  an  issue.  The  DSS  can  be  imple¬ 
mented  in  hardware,  software,  or  firmware,  but 
NSA’s  preferred  implementation  is  in  the  “FOR- 
TEZZA”  card. 

The  FORTEZZA  card  (formerly  called  the 
TESSERA  card)  is  a  Personal  Computer  Memory 
Card  Industry  Association  (PCMCIA)  card.55 
The  FORTEZZA  card  is  used  for  data  commu¬ 
nications;  it  implements  the  Skipjack  algorithm, 
as  well  as  key-exchange  and  digital-signature 
functions.  FORTEZZA  applications  include  the 
Defense  Departments’  Defense  Message  System. 
Per-workstation  costs  are  significantly  higher  for 
the  FORTEZZA  card  than  for  a  software-based 
signature  implementation  alone.  To  use  FOR¬ 
TEZZA,  agencies  must  have — or  upgrade  to — 
computers  with  PCMCIA  card  slots,  or  must  buy 
PCMCIA  readers  (about  $125  each). 

According  to  NSA,  current  full  costs  for  FOR¬ 
TEZZA  cards  are  about  $150  each  in  relatively 
small  initial  production  lots;  of  this  cost,  about 
$98  is  for  the  Capstone  chip.  About  3,000  FOR¬ 
TEZZA  cards  had  been  produced  as  of  April  1 995 
and  another  33,000  were  on  contract.  NSA  hopes 
to  award  a  large-scale  production  contract  in  fall 
1995  for  200,000  to  400,000  units.  In  these  quan¬ 
tities,  according  to  the  agency,  unit  costs  should  be 


52  See  OTA,  op.  cit.,  footnote  5,  p.  171. 

53  See  OTA,  op.  cit.,  footnote  1,  appendix  C,  especially  pp.  220-221.  For  a  more  recent  account  of  the  various  lawsuits  and  countersuits 
among  patent  holders,  licensers,  and  licensees,  see  Simson  Garfinkle,  PGP:  Pretty  Good  Privacy  (Sebastopol,  CA:  O’Reilly  and  Assoc.,  1 995), 
esp.  ch.  6. 

54  F.  Lynn  McNulty  et  al.,  NIST,  “Digital  Signature  Standard  Update,”  Oct.  1 1 , 1994.  The  government  offered  to  include  an  “authorization 
and  consent”  clause  under  which  the  government  would  assume  liability  for  any  patent  infringement  resulting  from  performance  of  a  contract, 
including  use  of  the  DSS  algorithm  or  public-key  certificates  by  private  parties  when  communicating  with  the  government.  See  also  OTA,  op. 
cit.,  footnote  5,  chapter  3. 

55  PCMCIA  cards  are  slightly  larger  than  a  credit  card,  with  a  connector  on  one  end  that  plugs  directly  into  a  standard  slot  in  a  computer  (or 
reader).  They  contain  microprocessor  chips;  for  example,  the  FORTEZZA  card  contains  a  Capstone  chip. 
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below  the  $100  per  unit  target  established  for  the 
program.56  Thus,  the  FORTEZZA  production 
contract  would  be  on  the  order  of  $20  million  to 
$40  million. 

NIST  is  working  on  what  is  intended  to  become 
a  market-driven  validation  system  for  vendors’ 
DSS  products.  This  is  being  done  within  the 
framework  of  overall  requirements  developed  for 
FIPS  140-1,  “Security  Requirements  for  Crypto¬ 
graphic  Modules”  (January  11,  1994).  NIST  is 
also  developing  a  draft  FIPS  for  “Cryptographic 
Service  Calls”  that  would  use  relatively  high-level 
application  program  interfaces  (e.g.,  “sign”  or 
verify  )  to  call  on  any  of  a  variety  of  crypto¬ 
graphic  modules.  The  intention  is  to  allow  flexi¬ 
bility  of  implementation  in  what  NIST  recognizes 
is  a  “hybrid  world.”  Unfortunately,  this  work  ap¬ 
pears  to  have  been  slowed  due  to  the  traditional 
scarcity  of  funds  for  such  core  security  programs 
at  NIST  (see  chapter  2  and  the  1994  OTA  report, 
pages  20  and  164). 

The  1996  Clinton  Administration  budget  pro¬ 
posals  reportedly  do  not  specify  funds  for  NIST 
work  related  to  the  DSS,  or  the  EES.57  However, 
according  to  the  draft  charter  of  the  Government 
Information  Technology  Services  Public-Key  In¬ 
frastructure  Federal  Steering  Committee,  NIST 
will  chair  and  provide  administrative  support  for 
the  Public-Key  Infrastructure  Federal  Steering 
Commmittee  that  is  being  formed  to  provide  guid¬ 
ance  and  assistance  in  developing  an  interoper¬ 
able,  secure  public-key  infrastructure  to  support 


electronic  commerce,  electronic  mail,  and  other 
applications. 

The  Advanced  Research  Projects  Agency 
(ARPA),  the  Defense  Information  Systems 
Agency  (DISA),  and  NSA  have  agreed  to  estab¬ 
lish  an  Information  Systems  Security  Research 
Joint  Technology  Office  (JTO)  to  coordinate  re¬ 
search  programs  and  long  range  strategic  planning 
for  information  systems  security  research  and  to 
expedite  delivery  of  security  technologies  to 
DISA.  Part  of  the  functions  of  the  JTO  will  be  to: 

■  Encourage  the  U.S.  industrial  base  to  develop 
commercial  products  with  built-in  security  to 
be  used  in  DOD  systems.  Develop  alliances 
with  industry  to  raise  the  level  of  security  in  all 
U.S.  systems.  Bring  together  private  sector 
leaders  in  information  security  to  advise  the 
JTO  and  build  consensus  for  the  resulting  pro¬ 
gram. 

■  Identify  areas  for  which  standards  need  to  be 
developed  for  information  systems  security. 

■  Facilitate  the  availability  and  use  of  NSA  certi¬ 
fied  cryptography  within  information  systems 
security  research  programs.5^ 

According  to  the  Memorandum  of  Agreement  es¬ 
tablishing  JTO,  its  work  is  intended  to  improve 
DISA  s  ability  to  safeguard  the  confidentiality,  in¬ 
tegrity,  authenticity,  and  availability  of  data  in  De¬ 
fense  Department  information  systems,  provide  a 
“robust  first  line  of  defense”  for  defensive  in¬ 
formation  warfare,  and  permit  electronic  com- 


Bob  Drake,  Legislative  Affairs  Office,  NSA,  personal  communication  Anr  7  1QQS  Tr» 
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merce  between  the  Defense  Department  and  its 
contractors.  (See  discussion  of  the  Defense  De¬ 
partment’s  “Information  Warfare”  activities  later 
in  this  chapter.) 

I  Private  Sector  Cryptography 
Developments59 

At  the  end  of  January  1995,  AT&T  Corp.  and 
VLSI  Technology,  Inc.,  announced  plans  to  devel¬ 
op  an  encryption  microchip  that  would  rival  the 
Clipper  and  Capstone  chips.  The  AT&T/VLSI 
chip  will  have  the  stronger,  triple-DES  imple¬ 
mentation  of  the  Data  Encryption  Standard  algo¬ 
rithm.60  It  is  intended  for  use  in  a  variety  of 
consumer  devices,  including  cellular  telephones, 
television  decoder  boxes  for  video-on-demand 
services,  and  personal  computers.61  The  AT&T/ 
VLSI  chips  do  not  include  key  escrowing.  Under 
current  export  regulations,  they  would  be  subject 
to  State  Department  export  controls. 

Industry  observers  consider  this  development 
especially  significant  as  an  indicator  of  the  lack  of 
market  support  for  Clipper  and  Capstone  chips  be¬ 
cause  AT&T  manufactures  a  commercial  product 
using  Clipper  chips  (the  AT&T  Surity  Telephone 
Device)  and  VLSI  is  the  NSA  contractor  making 
the  chips  that  Mykotronx  programs  (e.g.,  with  the 
Skipjack  algorithm  and  keys)  to  become  Clipper 
and  Capstone  chips. 


The  international  banking  and  financial  com¬ 
munities  have  long  used  encryption  and  authenti¬ 
cation  methods  based  on  the  DES.  Because  these 
communities  have  a  large  installed  base  of  DES 
technology;  a  transition  to  an  incompatible  (non- 
DES-based)  new  technology  would  be  lengthy. 
The  Accredited  Standards  Committee  X9,  which 
sets  data  security  standards  for  the  U.S.  banking 
and  financial  services  industries,  reportedly  an¬ 
nounced  that  it  will  develop  new  encryption  stan¬ 
dards  based  on  triple  DES  and  will  designate  a 
subcommittee  to  develop  technical  standards  for 
triple-DES  applications.62 

RSA  Data  Security,  Inc.,  recently  announced 
another  symmetric  encryption  algorithm,  called 
RC5.63  According  to  the  company,  RC5  is  faster 
than  the  DES  algorithm,  is  suitable  for  hardware 
or  software  implementation,  and  has  a  range  of 
user-selected  security  levels.  Users  can  select  key 
lengths  ranging  up  to  2,040  bits,  depending  on  the 
levels  of  security  and  speed  needed.  The  RSA  dig¬ 
ital  signature  system  (see  box  2-2  on  page  48), 
from  the  same  company,  is  the  leading  commer¬ 
cial  rival  to  the  Digital  Signature  Standard.  RSA- 
based  technology  is  also  part  of  a  new,  proposed 
industry  standard  for  protecting  business  transac¬ 
tions  on  the  Internet 64 

Another  private  sector  standards  group,  the 
IEEE  PI  363  working  group  on  public-key  cryp- 


59  This  section  highlights  selected  government  and  commercial  cryptography  developments  since  publication  of  the  1994  OTA  report.  This 
is  not  a  coomprehensive  survey  of  commercial  information -security  products  and  proposals.  Mention  of  individual  companies  or  products  is  for 
illustrative  purposes  and/or  identification  only,  and  should  not  be  interpreted  as  endorsement  of  these  products  or  approaches. 

60  In  “triple  DES,”  the  DES  algorithm  is  used  sequentially  with  three  different  keys,  to  encrypt,  decrypt,  then  re-encrypt.  Triple  encryption 
with  the  DES  offers  more  security  than  having  a  secret  key  that  is  twice  as  long  as  the  56-bit  key  specified  in  the  FIPS.  There  is,  however,  no  FIPS 
specifying  triple  DES. 

61  Jared  Sandberg  and  Don  Clark,  “AT&T,  VLSI  Technology  To  Develop  Microchips  That  Offer  Data  Security  ”  The  Wall  Street  Journal , 
Jan.  31,  1995;  see  also  Brad  Bass,  op.  cit.,  footnote  19. 

62  CIPHER  (Newsletter  of  the  IEEE  Computer  Society’s  TC  on  Security  and  Privacy),  Electronic  Issue  No.  4,  Carl  Landwehr  (ed.),  Mar.  1 0, 
1995,  available  from  (http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/cipher-archive.html). 

63  Ronald  L.  Rivest,  “The  RC5  Encryption  Algorithm,”  Dr.  Dobb’s  Journal,  January  1995,  pp.  146,  148. 

64  Peter  H.  Lewis,  “Accord  Is  Reached  on  a  Common  Security  System  for  the  Internet,”  The  New  York  Times ,  Apr.  11,  1995,  p.  D5.  The 
proposed  standard  will  be  used  to  safeguard  World  Wide  Web  services. 
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tography,  is  developing  a  voluntary  standard  for 
“RSA,  Diffie-Hellman,  and  Related  Public-Key 
Cryptography”  (see  figure  2-5  on  page  59).  The 
group  held  a  public  meeting  in  Oakland,  Califor¬ 
nia,  in  May  1995  to  review  a  draft  standard.65 

Several  companies  have  proposed  alternative 
approaches  to  key-escrow  encryption;  these  in¬ 
clude  some  20  different  alternatives  66  Variously, 
these  use  published,  unclassified  encryption  algo¬ 
rithms,  thus  potentially  allowing  software,  as  well 
as  hardware,  implementations.  The  commercial 
approaches  would  make  use  of  commercial  or  pri¬ 
vate  key-escrow  systems,  with  data  recovery  ser¬ 
vices  that  are  available  to  individuals  and 
organizations,  as  well  as  to  authorized  law  en¬ 
forcement  agencies. 

A  brief  description  of  two  of  the  commercial 
approaches  is  given  in  chapter  4,  based  on  in¬ 
formation  provided  by  Trusted  Information  Sys¬ 
tems  (TIS)  and  Bankers  Trust.  The  Bankers  Trust 
system  is  hardware-based;  the  TIS  system  is  soft- 
ware-based.  Bankers  Trust  has  proposed  its  sys¬ 
tem  to  the  U.S.  government  and  business 
community.  The  TIS  system  is  under  internal  gov¬ 
ernment  review  to  determine  the  sufficiency  of  the 
approach  to  meet  national  security  and  law  en¬ 
forcement  objectives. 

I  Business  Perspectives 

Representatives  of  major  U.S.  computer  and  soft¬ 
ware  companies  have  recently  reaffirmed  the  im¬ 
portance  of  security  and  privacy  protections  in  the 
developing  global  information  infrastructure 
(GII).67  But,  as  the  Computer  Systems  Policy 
Project’s  “Perspectives  on  the  Global  Information 


Infrastructure”  notes,  there  are  strong  and  serious 
business  concerns  that  government  interests,  es¬ 
pecially  in  the  standards  arena,  could  stifle  com¬ 
mercial  development  and  use  of  networks  in  the 
international  arena. 

In  June  1994,  the  Association  for  Computing 
Machinery  (ACM)  issued  a  report  on  the  policy  is¬ 
sues  raised  by  introduction  of  the  EES.  The  ACM 
report  identified  some  key  questions  that  need  to 
be  considered  in  reaching  conclusions  regarding: 

What  cryptography  policy  best  accommodates 
our  national  needs  for  secure  communications  and 
privacy,  industry  success,  effective  law  enforce¬ 
ment,  and  national  security?68 

The  U.S.  Public  Policy  Committee  of  the  ACM 
(USACM)  issued  a  companion  set  of  recommen¬ 
dations,  focusing  on  the  need  for: 

■  open  forums  for  cryptography  policy  develop¬ 
ment,  in  which  government,  industry,  and  the 
public  could  participate; 

■  encryption  standards  that  do  not  place  U.S. 
manufacturers  at  a  disadvantage  in  the  global 
marketplace  and  do  not  adversely  affect  tech¬ 
nological  development  within  the  United 
States; 

■  changes  in  FIPS  development,  such  as  placing 
the  process  under  the  Administrative  Proce¬ 
dures  Act; 

■  withdrawal  of  the  Clipper  chip  proposal  by  the 
Clinton  Administration  and  the  beginning  of  an 
open  and  public  review  of  encryption  policy; 
and 

■  development  of  technologies  and  institutional 
practices  that  will  provide  real  privacy  for  fu- 


65  Ibid.  Draft  sections  are  available  via  anonymous  ftp  to  rsa.com  in  the  “pub/p  1 363”  directory.  The  working  group’s  electronic  mailing  list 
is  <pl363@rsa.com>;  to  join,  send  e-mail  to  <pl363-request@rsa.com>. 

66  See  Dorothy  H.  Denning  and  Dennis  Branstad,  “A  Taxonomy  for  Key  Escrow  Encryption,”  forthcoming,  obtained  from  the  author  (den- 
ning@cs.georgetown.edu);  and  Elizabeth  Corcoran,  “Three  Ways  To  Catch  a  Code,”  Washington  Post ,  Mar.  16, 1995,  pp.  B 1 ,  B12.  The  Corco¬ 
ran  article  also  discusses  the  Hewlett-Packard  Co.’s  proposed  “national  flag  card”  approach  to  government-approved  encryption. 

67  See  Computer  Systems  Policy  Project,  Perspectives  on  the  Global  Information  Infrastructure ,  (Washington,  DC:  February  1995). 

68  Susan  Landau  et  al.,  Codes,  Keys,  and  Conflicts:  Issues  in  U.S.  Crypto  Policy  (New  York,  NY:  Association  for  Computing  Machinery, 
Inc.,  June  1994). 
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ture  users  of  the  National  Information  Infra¬ 
structure.69 

Also  in  1994,  the  International  Chamber  of 
Commerce  (ICC)  issued  its  “ICC  Position  Paper 
on  International  Encryption  Policy.”  ICC  noted 
the  growing  importance  of  cryptography  in  secur¬ 
ing  business  information  and  transactions  on  an 
international  basis  and,  therefore,  the  significance 
of  restrictions  and  controls  on  encryption  methods 
as  “artificial  obstacles”  to  trade.  ICC  urged  gov¬ 
ernments  “not  to  adopt  a  restrictive  approach 
which  would  place  a  particularly  onerous  burden 
on  business  and  society  as  a  whole.”70  ICC’s  posi¬ 
tion  paper  called  on  governments  to:  1)  remove 
unnecessary  export  and  import  controls,  usage  re¬ 
strictions,  restrictive  licensing  arrangements  and 
the  like  on  encryption  methods  used  in  commer¬ 
cial  applications;  2)  enable  network  interoperabil¬ 
ity  by  encouraging  global  standardization;  3) 
maximize  users’  freedom  of  choice;  and  4)  work 
together  with  industry  to  resolve  barriers  by  joint¬ 
ly  developing  a  comprehensive  international 
policy  on  encryption.  ICC  recommended  that 
global  encryption  policy  be  based  on  broad  prin¬ 
ciples  centered  on  openness  and  flexibility.71 

The  United  States  Council  for  International 
Business  (USCIB)  subsequently  issued  position 
papers  on  “Business  Requirements  for  Encryp¬ 
tion”72  and  “Liability  Issues  and  the  U.S.  Admin¬ 
istration’s  Encryption  Initiatives.”73  The  USCIB 
favored  breaking  down  the  “artificial  barriers”  to 
U.S.  companies’  competitiveness  and  ability  to 
implement  powerful  security  imposed  by  overly 
restrictive  export  controls.  The  Council  called  for 
international  agreement  on  “realistic”  encryption 
requirements,  including:  free  choice  of  encryption 


algorithms  and  key  management  methods,  public 
scrutiny  of  proposed  standard  algorithms,  free  ex¬ 
port/import  of  accepted  standards,  and  flexibility 
in  implementation  (i.e.,  hardware  or  software).  If 
key  escrowing  is  to  be  used,  the  USCIB  proposed 
that: 

■  a  government  not  be  the  sole  holder  of  the  entire 
key  except  at  the  discretion  of  the  user; 

■  the  key-escrow  agent  make  keys  available  to 
lawfully  authorized  entities  when  presented 
with  proper,  written  legal  authorizations  (in¬ 
cluding  international  cooperation  when  the  key 
is  requested  by  a  foreign  government); 

■  the  process  for  obtaining  and  using  keys  for 
wiretapping  purposes  must  be  auditable; 

■  keys  obtained  from  escrowing  agents  by  law 
enforcement  must  be  used  only  for  a  specified, 
limited  time  frame;  and 

■  the  owner  of  the  key  must  (also)  be  able  to  ob¬ 
tain  the  keys  from  the  escrow  agent.74 

The  USCIB  has  also  identified  a  number  of  dis¬ 
tinctive  business  concerns  regarding  the  U.S .  gov¬ 
ernment’s  position  on  encryption  and  liability: 

■  uncertainty  regarding  whether  the  Clinton  Ad¬ 
ministration  might  authorize  strict  government 
liability  for  misappropriation  of  keys,  includ¬ 
ing  adoption  of  tamper  proof  measures  to  ac¬ 
count  for  every  escrowed  unit  key  and  family 
key  (see  box  2-3); 

■  the  degree  of  care  underlying  design  of  Skip¬ 
jack,  EES,  and  Capstone  (given  the  govern¬ 
ment’s  still-unresolved  degree,  if  any,  of 
liability); 

■  the  confusion  concerning  whether  the  govern¬ 
ment  intends  to  disclaim  all  liability  in  connec- 


69  U.S.  Public  Policy  Committee  of  the  ACM,  “USACM  Position  on  the  Escrowed  Encryption  Standard,”  June  1994. 

70  International  Chamber  of  Commerce,  “ICC  Position  Paper  on  International  Encryption  Policy,”  Paris,  1994,  pp.  2,3.  See  also  United 
States  Council  for  International  Business,  Private  Sector  Leadership:  Policy  Foundations  for  a  National  Information  Infrastructure  (Nil),  July 
1994,  p  5. 

71  Ibid.,  pp.  3-4.  See  also  chapter  4  of  the  1994  OTA  report. 

72  United  States  Council  for  International  Business,  “Business  Requirements  for  Encryption,”  Oct.  10,  1994. 

73  United  States  Council  for  International  Business,  “Liability  Issues  and  the  U.S.  Administration’s  Encryption  Initiatives,”  Nov.  2,  1994. 

74  USCIB,  op.  cit.,  footnote  72,  pp.  3-4. 
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tion  with  the  EES  and  Capstone  initiatives,  and 
the  extent  to  which  family  keys,  unit  keys,  and 
law  enforcement  decryption  devices  will  be  ad¬ 
equately  secured;  and 

■  uncertainties  regarding  the  liability  of  nongov¬ 
ernmental  parties  (e.g.,  chip  manufacturers, 
vendors,  and  their  employees)  for  misconduct 
or  negligence.75 

These  types  of  concerns  have  remained  unre¬ 
solved  (see  related  discussion  and  options  pres¬ 
ented  in  the  1994  OTA  report,  pages  16-18  and 
171-182). 

Liability  issues  are  important  to  the  develop¬ 
ment  of  electronic  commerce  and  the  underpin¬ 
ning  institutional  infrastructures,  including  (but 
not  limited  to)  escrow  agents  for  key-escrowed 
encryption  systems  and  certificate  authorities  for 
public-key  infrastructures.  Widespread  use  of  cer¬ 
tificate-based,  public-key  infrastructures  will  re¬ 
quire  resolution  and  harmonization  of  liability 
requirements  for  trusted  entities,  whether  these  be 
federal  certificate  authorities,  private  certificate 
(or  “certification”)  authorities,  escrow  agents, 
banks,  clearinghouses,  value-added  networks,  or 
other  entities.76 

There  is  increasing  momentum  toward  frame¬ 
works  within  which  to  resolve  legal  issues  per¬ 
taining  to  digital  signatures  and  to  liability.  For 
example: 

■  The  Science  and  Technology  Section  of  the 
American  Bar  Association’s  Information  Secu¬ 
rity  Committee  is  drafting  “Global  Digital  Sig¬ 
nature  Guidelines”  and  model  digital-signature 
legislation. 

■  With  participation  by  the  International  Cham¬ 
ber  of  Commerce  and  the  U.S.  State  Depart¬ 
ment,  the  United  Nations  Commission  on 


International  Trade  Law  has  completed  a  Mod¬ 
el  Law  on  electronic  data  interchange  (EDI). 

■  Utah  has  just  enacted  digital  signature  legisla¬ 
tion.77 

I  Privacy  Legislation 

In  the  104th  Congress,  bills  have  been  introduced 
to  address  the  privacy-related  issues  of  search  and 
seizure,  access  to  personal  records,  content  of 
electronic  information,  drug  testing,  and  im¬ 
migration  and  social  security  card  fraud  problems. 
In  addition,  Representative  Cardiss  Collins  has  re¬ 
introduced  the  “Individual  Privacy  Protection  Act 
of  1995”  (H.R.  184).  H.R.  184  includes  provi¬ 
sions  to  establish  a  Privacy  Protection  Commis¬ 
sion  charged  with  ensuring  the  privacy  rights  of 
U.S.  citizens,  providing  advisory  guidance  on 
matters  related  to  electronic  data  storage,  and  pro¬ 
moting  and  encouraging  the  adoption  of  fair  in¬ 
formation  practices  and  the  principle  of  collection 
limitation.. 

Immigration  concerns  and  worker  eligibility 
are  prompting  reexamination  of  social  security 
card  fraud  and  discussion  over  a  national  identifi¬ 
cation  database.  At  least  eight  bills  have  been 
introduced  in  the  104th  Congress  to  develop  tam¬ 
per-proof  or  counterfeit-resistant  social  security 
cards  (H.R.  560,  H.R.  570,  H.R.  756,  H.R.  785) 
and  to  promote  research  toward  a  national  identifi¬ 
cation  database  (H.R.  502,  H.R.  195,  S.  456,  S. 
269). 

Four  bills  have  been  introduced  modifying 
search  and  seizure  limitations:  H.R.  3,  H.R.  666, 
S.  3,  and  S.  54.  The  “Exclusionary  Rule  Reform 
Act  of  1995”  (H.R.  666  and  companion  S.  54), 
which  revises  the  limitations  on  evidence  found 
during  a  search,  passed  the  House  on  February  10, 


75  USCIB,  op.  cit.,  footnote  73,  pp.  2-6. 

76  See  ibid,  for  discussion  of  liability  exposure,  legal  considerations,  tort  and  contract  remedies,  government  consent  to  be  liable,  and  rec¬ 
ommendations  and  approaches  to  mitigate  liability. 

77  Information  on  American  Bar  Association  and  United  Nations  activities  provided  by  Michael  Baum,  Principal,  Independent  Monitoring, 
personal  communication,  Mar.  19,  1995.  See  also  Michael  S.  Baum,  Federal  Certification  Authority  Liability  and  Policy:  Law  and  Policy  of 
Certificate-Based  Public  Key  and  Digital  Signatures,  NIST-GCR-94-654,  NTIS  Doc.  No.  PB94-191-202  (Springfield,  VA:  National  Technical 
Information  Service,  1994). 


24 1  Issue  Update  on  Information  Security  and  Privacy  in  Network  Environments 


1995.  Similar  provisions  have  been  included  in 
crime  legislation  introduced  in  both  houses,  S.  3 
and  H.R.  3.  The  Senate  Committee  on  the  Judicia¬ 
ry  has  held  a  hearing  on  Title  V  of  S.  3,  the  provi¬ 
sions  reforming  the  exclusionary  rule. 

Also  this  session,  legislation  has  been 
introduced  increasing  privacy  protection  by  re¬ 
stricting  the  use  or  sale  of  lists  collected  by  com¬ 
munication  carriers  (H.R.  411)  and  the  U.S.  Postal 
Service  (H.R.  434),  defining  personal  medical  pri¬ 
vacy  rights  (H.R.  435,  S.  7),  detailing  acceptable 
usage  of  credit  report  information  (H.R.  561),  and 
mandating  procedures  for  determining  the  reli¬ 
ability  of  drug  testing  (H.R.  153).  These  bills  es¬ 
tablish  guidelines  in  specific  areas,  but  do  not 
attempt  to  address  the  overall  challenges  facing 
privacy  rights  in  an  electronic  age. 

The  “Family  Privacy  Bill”  (H.R.  1271)  passed 
the  House  on  April  4,  1995.  H.R.  1271,  intro¬ 
duced  by  Representative  Steve  Horn  on  March  21 , 
1995,  is  intended  to  provide  parents  the  right  to 
supervise  and  choose  their  children’s  participation 
in  any  federally  funded  survey  or  questionnaire 
that  involves  intrusive  questioning  on  sensitive  is¬ 
sues.78  Some  have  raised  concerns  about  the  bill 
on  the  grounds  that  it  might  dangerously  limit  lo¬ 
cal  police  authority  to  question  minors  and  threat¬ 
en  investigations  of  child  abuse,  or  hinder  doctors 
in  obtaining  timely  patient  information  on  chil¬ 
dren.79 

In  addition,  the  Office  of  Management  and 
Budget  recently  published  notice  of  draft  privacy 
principles  and  draft  security  tenets  for  the  national 
information  infrastructure.80  The  draft  privacy 
principles  were  developed  by  the  Information  In¬ 
frastructure  Task  Force’s  Working  group  on  Priva¬ 


cy  and  are  intended  to  update  and  revise  the  Code 
of  Fair  Information  Practices  developed  in  the  ear¬ 
ly  1970s  and  used  in  development  of  the  Privacy 
Act  of  1974. 

I  Information-Security  Policy 
Initiatives  and  Legislation 

The  Defense  Department’s  “Information  Warfare” 
activities  address  the  opportunities  and  vulnera¬ 
bilities  inherent  in  its  (and  the  country’s)  increas¬ 
ing  reliance  on  information  and  information 
systems.  The  Department  has  a  variety  of  In¬ 
formation  Warfare  activities  ongoing  in  its  ser¬ 
vices  and  agencies,  the  Office  of  the  Secretary  of 
Defense,  and  elsewhere.81  The  Department’s  De¬ 
fensive  Information  Warfare  program  goals  focus 
on  technology  development  to  counter  vulnerabil¬ 
ities  stemming  from  the  Department’s  growing 
dependence  on  information  systems  and  the  com¬ 
mercial  information  infrastructure  (e.g.,  the  pub¬ 
lic-switched  network  and  the  Internet).  The 
Information  Systems  Security  Research  Joint 
Technology  Office  established  by  ARPA,  DISA, 
and  NS  A  (see  above)  will  pursue  research  and  de¬ 
velopment  pursuant  to  these  goals. 

The  increasing  prominence  of  Information 
Warfare  issues  has  contributed  to  an  increasing 
momentum  for  consolidating  information-securi¬ 
ty  authorities  government-wide,  thereby  expand¬ 
ing  the  role  of  the  defense  and  intelligence 
agencies  for  unclassified  information  security 
overall: 

.  . .  Protection  of  U.S.  information  systems  is 
also  clouded  by  legal  restrictions  put  forth,  for  ex¬ 
ample,  in  the  Computer  Security  Act  of  1987. 


78  Representative  Scott  Mclnnis,  Congressional  Record ,  Apr.  4,  1995,  p.  H4126. 

79  Representative  Cardiss  Collins,  Congressional  Record ,  Apr.  4,  1995,  p.  H4126. 

80  Office  of  Management  and  Budget,  “National  Information  Infrastructure:  Draft  Principles  for  Providing  and  Using  Personal  Information 
and  Commentary,”  Federal  Register,  vol.  60,  No.  13,  Jan.  20, 1995,  pp.  4362-4370.  These  were  developed  by  the  Privacy  Working  Group  of  the 
Information  Policy  Committee,  Information  Infrastructure  Task  Force  (IITF).  See  also  Office  of  Management  and  Budget,  “Draft  Security  Te¬ 
nets  for  the  National  Information  Infrastructure,”  Federal  Register,  vol.  60,  No.  28,  Feb.  10, 1995,  p.  8 100.  These  were  developed  by  the  Securi¬ 
ty  Issues  Forum  of  the  IITF. 

81  See,  e.g.,  “Report  of  the  Defense  Science  Board  Summer  Study  Task  Force  on  Information  Architecture  for  the  Battlefield,”  Office  of  the 
Under  Secretary  of  Defense  for  Acquisition  and  Technology,  October  1994. 
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Of  concern  to  the  Task  Force  is  the  fact  that  IW 
[Information  Warfare]  technologies  and  capabili¬ 
ties  are  largely  being  developed  in  an  open  com¬ 
mercial  market  and  are  outside  of  direct 
Government  control.82 

Such  a  consolidation  and/or  expansion  would  run 
counter  to  current  statutory  authorities  and  to 
OMB’s  proposed  new  government-wide  security 
and  privacy  policy  guidance  (see  below). 

The  Joint  Security  Commission 

In  mid-1993,  the  Joint  Security  Commission  was 
convened  by  the  Secretary  of  Defense  and  the  Di¬ 
rector  of  Central  Intelligence  to  develop  a  “new 
approach  to  security  that  would  assure  the  adequa¬ 
cy  of  protection  within  the  contours  of  a  security 
system  that  is  simplified,  more  uniform,  and  more 
cost  effective.”83  The  Joint  Security  Commis¬ 
sion’s  report  made  recommendations  across  a 
comprehensive  range  of  areas. 

The  sections  on  information  systems  security84 
and  a  security  architecture  for  the  future85  are  of 
special  interest.  In  the  context  of  the  Commis¬ 
sion’s  charter,  they  propose  a  unified  security 
policy  structure  and  authority  for  classified  and 
unclassified  information  in  the  defense/intelli¬ 
gence  community.86  However,  the  report  also  rec¬ 
ommends  a  more  general  centralization  of 
information  security  along  these  lines  govern¬ 
ment-wide;  the  executive  summary  highlights  the 
conclusion  the  security  centralization  within  the 
defense/intelligence  community  described  in  the 


report  should  be  extended  government- wide. 87 
The  report  also  recommends  “establishment  of  a 
national  level  security  policy  committee  to  pro¬ 
vide  structure  and  coherence  to  U.S.  government 
security  policy,  practices,  and  procedures.”88 

The  Security  Policy  Board 

On  September  16, 1994,  President  Clinton  signed 
Presidential  Decision  Directive  29  (PDD-29). 
PDD-29,  “Security  Policy  Coordination,”  estab¬ 
lished  a  new  structure,  under  the  direction  of  the 
National  Security  Council  (NSC),  for  the  coor¬ 
dination,  formulation,  evaluation,  and  oversight 
of  U.S.  security  policy.89  According  to  the  de¬ 
scription  of  PDD-29  provided  to  OTA  by  NSC, 
the  directive  designates  the  former  Joint  Security 
Executive  Committee  established  by  the  Secre¬ 
tary  of  Defense  and  the  Director  of  Central  Intelli¬ 
gence  as  the  Security  Policy  Board. 

The  Security  Policy  Board  (SPB)  subsumes  the 
functions  of  a  number  of  previous  national  securi¬ 
ty  groups  and  committees.  The  SPB  members  in¬ 
clude  the  Director  of  Central  Intelligence,  Deputy 
Secretary  of  Defense,  Vice  Chairman  of  the  Joint 
Chiefs  of  Staff,  Deputy  Secretary  of  State,  Under 
Secretary  of  Energy,  Deputy  Secretary  of  Com¬ 
merce,  and  Deputy  Attorney  General;  plus  one 
Deputy  Secretary  from  “another  non-defense-re- 
lated-agency”  selected  on  a  rotating  basis,  and  one 
representative  each  from  the  OMB  and  NSC  staff. 

The  Security  Policy  Forum  that  had  been  estab¬ 
lished  under  the  Joint  Security  Executive  Com- 


82  Ibid.,  p.  52. 

83  Joint  Security  Commission,  “Redefining  Security:  A  Report  to  the  Secretary  of  Defense  and  Director  of  Central  Intelligence,”  Feb.  28, 
1994  (quote  from  letter  of  transmittal).  See  also  U.S.  Congress,  House  of  Representatives,  Permanent  Select  Committee  on  Intelligence,  “Intelli¬ 
gence  Authorization  Act  for  Fiscal  Year  1994,”  Rept.  103-162,  Part  I,  103d  Congress,  1st  session,  June  29,  1993,  pp.  26-27. 

84  Joint  Security  Commission,  ibid.,  pp.  101-113. 

85  Ibid.,  pp.  127  et  seq. 

86  Ibid.,  p.  105,  first  paragraph.;  p.  110,  recommendation;  pp.  127-130. 

87  Ibid.,  p.  viii,  top. 

88  Ibid.,  p.  130. 

89  Although  it  is  unclassified,  PDD-29  has  not  been  released.  This  discussion  is  based  on  a  fact  sheet  provided  to  OTA  by  NSC;  the  fact  sheet 
is  said  to  be  a  “nearly  verbatim  text  of  the  PDD,”  with  the  only  differences  being  “minor  grammatical  ones.”  David  S.  Van  Tassel  (Director, 
Access  Management,  NSC),  letter  to  Joan  Winston  (OTA),  and  enclosure,  Feb.  16,  1995. 
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mittee  was  retained  under  the  SPB.  The  forum  is 
composed  of  senior  representatives  from  over  two 
dozen  defense,  intelligence,  and  civilian  agencies 
and  departments;  the  forum  chair  is  appointed  by 
the  SPB  chair.  The  Security  Policy  Forum  func¬ 
tions  are  to:  consider  security  policy  issues  raised 
by  its  members  or  others,  develop  security  policy 
initiatives  and  obtain  comments  for  the  SPB  from 
departments  and  agencies,  evaluate  the  effective¬ 
ness  of  security  policies,  monitor  and  guide  the 
implementation  of  security  policies  to  ensure  co¬ 
herence  and  consistency,  and  oversee  application 
of  security  policies  to  ensure  they  are  equitable 
and  consistent  with  national  goals.90 

PDD-29  also  established  a  Security  Policy  Ad¬ 
visory  Board  of  five  members  from  industry.  This 
independent,  nongovernmental  advisory  board  is 
intended  to  advise  the  President  on  implementa¬ 
tion  of  the  policy  principles  guiding  the  “new” 
formulation,  evaluation,  and  oversight  of  U.S.  se¬ 
curity  policy,  and  to  provide  the  SPB  and  the  intel¬ 
ligence  community  with  a  “public  interest” 
perspective.  The  SPB  is  authorized  to  establish  in¬ 
teragency  working  groups  as  necessary  to  carry 
out  its  functions  and  to  ensure  interagency  input  to 
and  coordination  of  security  policy,  procedures, 
and  practices,  with  staffs  to  support  the  SPB  and 
any  other  groups  or  fora  established  pursuant  to 
PDD-29. 

PDD-29  was  not  intended  to  change  or  amend 
existing  authorities  or  responsibilities  of  the 
members  of  the  SPB,  as  “contained  in  the  Nation¬ 
al  Security  Act  of  1947,  other  existing  laws  or 
Executive  Orders.”91  PDD-29  does  not  refer  spe¬ 
cifically  to  government  information  security 
policy,  procedures,  and  practices,  or  to  unclassi¬ 
fied  information  security  government-wide.  Nev¬ 
ertheless,  the  proposed  detailed  implementation 


of  the  directive  with  respect  to  information  securi¬ 
ty,  as  articulated  in  the  Security  Policy  staff  report 
report,  “Creating  a  New  Order  in  U.S.  Security 
Policy,”  is  a  departure  from  the  information  secu¬ 
rity  structure  set  forth  in  the  Computer  Security 
Act  of  1987.  The  staff  report  appears  to  recognize 
this  mismatch  between  its  proposal  and  statutory 
authorities  for  unclassified  information  security, 
noting  the  Computer  Security  Act  under  informa¬ 
tion-security  “actions  required”  to  implement 
PDD-29.92 

The  SPB  staff’s  proposed  “new  order”  for  in¬ 
formation  security  builds  on  the  Joint  Security 
Commission’s  analysis  and  recommendations  to 
establish  a  “unifying  body”  government-wide.93 
With  respect  to  information  security,  the  new  SPB 
structure  would  involve  organizing  an  Informa¬ 
tion  Systems  Security  Committee  (ISSC)  charged 
with  “coupling  the  development  of  policy  for  both 
the  classified  and  the  sensitive  but  unclassified 
communities”  and  a  “transition  effort”  for  conver¬ 
sion  to  the  new  structure.94 

This  “comprehensive  structure”  would  be  the 
new  ISSC,  that  would  be: 

. . .  based  on  the  foundation  of  the  current 
NSTISSC  [see  appendix  B  of  this  background  pa¬ 
per  ]  but  will  have  responsibility  for  both  the  classi¬ 
fied  and  the  sensitive  but  unclassified  world. 

The  ISSC  would  be  jointly  chaired  at  the  SES 
[Senior  Executive  Service]  or  General  Officer  level 
by  DOD  and  OMB.  This  new  body  would  consist  of 
voting  representatives  from  each  of  the  agencies/ 
departments  currently  represented  on  the 
NSTISSC  and  its  two  subcommittees,  NIST  and  the 
civil  agencies  it  represents,  and  other  appropriate 
agencies/departments,  such  as  DISA,  which  are 
currently  not  represented  on  the  NSTISSC.  This 


90  Ibid,  (fact  sheet). 

91  Ibid. 

92  U.S.  Security  Policy  Board  Staff,  “Creating  a  New  Order  in  U.S.  Security  Policy,”  Nov.  21,  1994.  p.  18. 

93  Ibid.,  p.  3.  See  Elizabeth  Sikorovsky,  “NSC  Proposes  To  Shift  Policy-Making  Duties,”  Federal  Computer  Week,  Jan.  23, 1995,  pp.  1 , 45. 
See  also  Kevin  Power,  “Administration  Floats  New  Information  Security  Policy,”  Government  Computer  News,  Jan.  23,  1995,  p.  59. 

94  U.S.  Security  Policy  Board  Staff ,  op.  cit.,  footnote  92,  pp.  II-III,  p.  15. 
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body  would  create  working  groups  as  needed  to  ad¬ 
dress  topics  of  interest. 

The  IS  SC  would  eventually  have  authority  over 
all  classified  and  unclassified  but  sensitive  sys¬ 
tems,  and  would  report  to  through  the  [Security 
Policy]  Forum  and  Board  to  the  NSC.  Thus,  poli¬ 
cies  would  have  the  full  force  and  authority  of  an 
NSC  Directive,  rather  than  the  relatively  “tooth¬ 
less”  issuances  currently  emanating  from  the 
NSTISSC.  NSA  would  continue  to  provide  the  sec¬ 
retariat  to  the  new  national  INFOSEC  structure, 
since  the  secretariat  is  a  well-functioning,  highly- 
efficient,  and  effective  body. 

.  . .  A  joint  strategy  would  have  to  be  devised  for 
a  smooth  transition  between  the  current  and  new 
structures,  which  would  ensure  that  current  mo¬ 
mentum  is  maintained  and  continuity  preserved.  In 
addition,  a  new  definition  must  be  developed  for 
“ national  security  information,  ”  and  it  must  be  de¬ 
termined  how  such  information  relates  to  the  uncla- 
sified  arena  from  a  national  security  standpoint 
[emphasis  added].  Issues  such  as  voting  in  such  a 
potentially  unwieldy  organization  must  also  be  re¬ 
solved.95 

At  this  writing,  the  extent  to  which  the  SPB  in¬ 
formation-security  proposals,  ISSC,  and  the  de¬ 
velopment  of  a  new  definition  of  “national 
security  information”  have  or  have  not  been  “en¬ 
dorsed”  within  the  executive  branch  is  unclear. 
Outside  the  executive  branch,  however,  they  have 
been  met  with  concern  and  dismay  reminiscent  of 
reactions  to  NSDD-145  a  decade  ago  (see  chapter 
2  and  appendix  B).96  Moreover,  they  run  counter 
to  the  statutory  agency  authorities  set  forth  in  the 
104th  Congress  in  the  Paperwork  Reduction  Act 
of  1995  (see  below),  as  well  as  in  the  Computer 


Security  Act  of  1987.  At  its  March  23-24,  1995 
meeting,  the  Computer  Systems  Security  and  Pri¬ 
vacy  Board  that  was  established  by  the  Computer 
Security  Act  issued  Resolution  95-3,  recommend¬ 
ing  that  the  SPB  await  broader  discussion  of  is¬ 
sues  before  proceeding  with  its  plans  “to  control 
unclassified,  but  sensitive  systems.” 

Concerns  have  also  been  expressed  within  the 
executive  branch.  The  ISSC  information  security 
structure  that  would  increase  the  role  of  the  de¬ 
fense  and  intelligence  communities  in  govern¬ 
mentwide  unclassified  information  security  runs 
counter  to  the  Clinton  Administration’s  “basic  as¬ 
sumptions”  about  free  information  flow  and  pub¬ 
lic  accessibility  as  articulated  in  the  1993  revision 
of  OMB  Circular  A- 130,  “Management  of  Federal 
Information  Resources.”97 

Moreover,  some  senior  federal  computer  secu¬ 
rity  managers  have  expressed  concern  about  what 
they  consider  premature  implementation  of  the 
SPB  staff  report’s  proposed  centralization  of  in¬ 
formation  security  functions  and  responsibilities. 
In  a  January  11,  1995,  letter  to  Sally  Katzen,  Di¬ 
rector  of  the  Office  of  Information  and  Regulatory 
Affairs,  Office  of  Management  and  Budget  (re¬ 
leased  March  23,  1995),  the  Steering  Committee 
of  the  Federal  Computer  Security  Program  Man¬ 
ager’s  Forum98  indicated  “unanimous  disagree¬ 
ment”  with  the  Security  Policy  Board’s  (SPB) 
proposal  and  urged  OMB  to  “take  appropriate  ac¬ 
tion  to  restrict  implementation  of  the  SPB  report 
to  only  classified  systems.”99  This  type  of  restric¬ 
tion  appears  to  have  been  incorporated  in  the  pro¬ 
posed  revision  to  Appendix  III  of  OMB  Circular 
A- 130  (see  below). 


95  Ibid.,  pp.  17-18.  See  appendix  B  of  this  paper  and  OTA,  op.  cit.,  footnote  5,  pp.  132-148  for  discussion  of  NSDD-145,  the  intent  of  the 
Computer  Security  Act  of  1987,  and  NSTISSC. 

96  See  Neil  Munro,  “White  House  Security  Panels  Raise  Hackles,”  Washington  Technology ,  Feb.  23,  1995,  pp.  6,  8. 

97  OMB  Circular  A-130 — Revised,  June  25,  1993,  Transmittal  Memorandum  No.  1,  sec.  7. 

98  The  Federal  Computer  Security  Program  Manager’s  Forum  is  made  up  of  senior  computer  security  managers  for  civilian  agencies,  in¬ 
cluding  the  Departments  of  Commerce,  Health  and  Human  Services,  Justice,  and  Transportation.  The  January  1 1 ,  1995,  letter  to  Sally  Katzen. 
Director  of  the  Office  of  Information  and  Regulatory  Affairs,  Office  of  Management  and  Budget,  was  signed  by  Lynn  McNulty,  Forum  Chair 
(National  Institute  of  Standards  and  Technology)  and  Sadie  Pitcher,  Forum  Co-chair  (Department  of  Commerce).  Text  of  letter  taken  from  the 
online  EPIC  Alert,  vol.  2.05,  Mar.  27,  1995. 

99  Ibid. 
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In  March  and  April  1995,  OTA  invited  the  Se¬ 
curity  Policy  Board  staff  to  comment  on  draft 
OTA  text  discussing  information-security  central¬ 
ization,  including  the  Joint  Security  Commission 
report,  PDD-29,  and  the  SPB  staff  report.  OTA  re¬ 
ceived  SPB  staff  comments  in  early  May  1995,  as 
this  background  paper  was  in  press.  According  to 
the  Security  Policy  Board  staff  director,  informa¬ 
tion  systems  security  policy  is  a  “work  in  progress 
in  its  early  stages”  for  the  SPB  and  the  staff  report 
was  intended  to  be  a  “strawman”  starting  point  for 
discussion.  Moreover,  according  to  the  SPB  staff, 
“recognizing  the  sensitivity  and  complexity  of  In¬ 
formation  Systems  Security  policy,  the  ISSC  was 
not  one  of  the  committees  which  was  established, 
nor  was  a  transition  team  formed.”100  In  order  to 
provide  as  much  information  as  possible  for  con¬ 
sideration  of  information  security  issues,  includ¬ 
ing  the  SPB  staff  perspective,  OTA  has  included 
the  SPB  staff  comments  in  box  1-3. 

The  Paperwork  Reduction  Act  of  1995 

The  Paperwork  Reduction  Act  was  reauthorized 
in  the  104th  Congress.  The  House  and  Senate  ver¬ 
sions  of  the  Paperwork  Reduction  Act  of  1995 
(H.R.  830  and  S.244)  both  left  existing  agency  au¬ 
thorities  under  the  Computer  Security  Act  of  1987 
unchanged.101  The  Paperwork  Reduction  Act  of 
1995  (Public  Law  104-13)  was  reported  on  April 
3,  1995, 102  passed  in  both  Houses  on  April  6, 
1995,  and  signed  by  President  Clinton  on  May  22, 
1995. 


Among  its  goals,  the  Paperwork  Reduction  Act 
of  1995  is  intended  to  make  federal  agencies  more 
responsible  and  publicly  accountable  for  informa¬ 
tion  management.  With  respect  to  safeguarding 
information,  the  act  seeks  to: 

. . .  ensure  that  the  creation,  collection,  mainte¬ 
nance,  use,  dissemination,  and  disposition  of  in¬ 
formation  by  or  for  the  Federal  Government  is 
consistent  with  applicable  laws,  including  laws  re¬ 
lating  to — 

(A)  privacy  and  confidentiality,  including  sec¬ 
tion  552a  of  Title  5; 

(B)  security  of  information,  including  the  Com¬ 
puter  Security  Act  of  1987  (Public  Law 
100-235);  and 

(C)  access  to  information,  including  section 
552  of  Title  5. 103 

With  respect  to  privacy  and  security,  the  Paper¬ 
work  Reduction  Act  of  1995  provides  that  the  Di¬ 
rector  of  OMB  shall: 

1.  develop  and  oversee  the  implementation  of 
policies,  principles,  standards,  and  guide¬ 
lines  on  privacy,  confidentiality,  security, 
disclosure,  and  sharing  of  information  col¬ 
lected  or  maintained  by  or  for  agencies; 

2.  oversee  and  coordinate  compliance  with 
sections  552  and  552a  of  title  5,  the  Comput¬ 
er  Security  Act  of  1987  (40  U.S.C.  759  note), 
and  related  information  management  laws; 
and 

3.  require  Federal  agencies,  consistent  with  the 
Computer  Security  Act  of  1987  (40  U.S.C. 

59  note),  to  identify  and  afford  security 


100  Peter  D.  Saderholm  (Director,  Security  Policy  Board  Staff),  memorandum  for  Joan  D.  Winston  and  Miles  Ewing  (OTA),  SPB  095-95, 
May  4,  1995. 

101  Senator  William  V.  Roth,  Jr.,  Congressional  Record ,  Mar.  6,  1995,  p.  S3512. 

102  U.S.  Congress,  House  of  Representatives,  “Paperwork  Reduction  Act  of  1995 — Conference  Report  to  Accompany  S.244,”  H.  Rpt. 
104-99,  Apr.  3, 1995.  As  the  “Joint  Explanatory  Statement  of  the  Committee  of  the  Conference”  (ibid.,  pp.  27-39)  notes,  the  1995  act  retains  the 
legislative  history  of  the  Paperwork  Reduction  Act  of  1980.  Furthermore,  the  definition  of  “information  technology”  in  the  1 995  act  is  intended 
to  preserve  the  exemption  for  military  and  intelligence  information  technology  that  is  found  in  current  statutory  definitions  of  “automatic  data 
processing.”  The  1995  act  accomplishes  this  by  referring  to  the  so-called  Warner  Amendment  exemptions  to  the  Brooks  Act  of  1965  and,  thus, 
to  section  1 1 1  of  the  Federal  Property  and  Administrative  Services  Act  (ibid.,  pp.  28-29).  See  also  discussion  of  the  Warner  Amendment  exemp¬ 
tions  from  the  FIPS  and  the  Computer  Security  Act  in  appendix  B  of  this  background  paper. 

103  Ibid.,  sec.  3501(8).  The  act  amends  chapter  35  of  title  44  U.S.C. 
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protections  commensurate  with  the  risk  and 
magnitude  of  the  harm  resulting  from  the 
loss,  misuse,  or  unauthorized  access  to  or 
modification  of  information  collected  or 
maintained  by  or  on  behalf  of  an  agency.104 

The  latter  requirement  for  cost-effective  securi¬ 
ty  implementation  and  standards  is  tied  to  the 
roles  of  the  Director  of  NIST  and  the  Administra¬ 
tor  of  General  Services  in  helping  the  OMB  to: 

(A)  develop  and  oversee  the  implementation  of 
polices,  principles,  standards,  and  guide¬ 
lines  for  information  technology  functions 
and  activities  of  the  Federal  Government, 
including  periodic  evaluations  of  major  in¬ 
formation  systems;  and 

(B)  oversee  the  development  and  implementa¬ 
tion  of  standards  under  section  111(d)  of  the 
Federal  Property  and  Administrative  Ser¬ 
vices  Act  of  1949  (40  U.S.C.  759(d)).105 

Federal  agency  heads  are  responsible  for  ensuring 
that  their  agencies  shall: 

1.  implement  and  enforce  applicable  policies, 
procedures,  standards,  and  guidelines  on 
privacy,  confidentiality,  security,  disclosure, 
and  sharing  of  information  collected  or 
maintained  by  or  for  the  agency; 

2.  assume  responsibility  and  accountability  for 
compliance  with  and  coordinated  manage¬ 
ment  of  sections  552  and  552a  of  title  5,  the 
Computer  Security  Act  of  1987  (40  U.S.C. 
759  note),  and  related  information  manage¬ 
ment  laws;  and 

3.  consistent  with  the  Computer  Security  Act 
of  1987  (40  U.S.C.  59  note),  identify  and  af¬ 
ford  security  protections  commensurate 
with  the  risk  and  magnitude  of  the  harm 
resulting  from  the  loss,  misuse,  or  unau¬ 
thorized  access  to  or  modification  of  in¬ 


formation  collected  or  maintained  by  or  on 
behalf  of  an  agency.106 

Proposed  Revision  of  Appendix  III 
of  OMB  Circular  A-130 

At  this  writing,  OMB  had  just  completed  the  pro¬ 
posed  revision  of  Appendix  III.  The  proposed  re¬ 
vision  is  intended  to  lead  to  improved  federal 
information-security  practices  and  to  make  fulfill¬ 
ment  of  Computer  Security  Act  and  Privacy  Act 
requirements  more  effective  generally,  as  well  as 
with  respect  to  data  sharing  and  secondary  uses. 
As  indicated  above,  the  Paperwork  Reduction  Act 
of  1995  has  affirmed  OMB’s  government- wide 
authorities  for  information  security  and  privacy. 

The  new,  proposed  revision  of  Appendix  III 
(“Security  of  Federal  Automated  Information”) 
will  be  key  to  assessing  the  prospect  for  improved 
federal  information  security  practices.  The  pro¬ 
posed  revision  was  posted  for  public  comment  on 
March  29,  1995.  According  to  OMB,  the  pro¬ 
posed  new  government-wide  guidance: 

...  is  intended  to  guide  agencies  in  securing  in¬ 
formation  as  they  increasingly  rely  on  an  open  and 
interconnected  National  Information  Infrastruc¬ 
ture.  It  stresses  management  controls  such  as  indi¬ 
vidual  responsibility,  awareness  and  training,  and 
accountability,  rather  than  technical  controls  .  .  . 

The  proposal  would  also  better  integrate  securi¬ 
ty  into  program  and  mission  goals,  reduce  the  need 
for  centralized  reporting  of  paper  security  plans, 
emphasize  the  management  of  risk  rather  than  its 
measurement,  and  revise  government-wide  securi¬ 
ty  responsibilities  to  be  consistent  with  the  Com¬ 
puter  Security  Act.107 

According  to  OMB,  the  proposed  new  security 
guidance  reflects  the  significant  differences  in  ca- 


104  Ibid.,  sec.  3504(g).  The  OMB  Director  delegates  authority  to  administer  these  functions  to  the  Administrator  of  OMB’s  Office  of  In¬ 
formation  and  Regulatory  Affairs. 

105  Ibid.,  section  3504(h)(1).  See  also  “Joint  Explanatory  Statement  of  the  Committee  of  the  Conference,”  ibid.,  pp.  27-29. 

106  Ibid.,  section  3506(g). 

107  Office  of  Management  and  Budget,  “Security  of  Federal  Automated  Information,”  Proposed  Revision  of  OMB  Circular  No.  A- 1 30  Ap¬ 
pendix  III  (transmittal  memorandum),  available  via  World  Wide  Web  at  http://csrc.ncsl.nist.gov/secplcy  as  <al30app3.txt>. 
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80X 1  -3:  Security  Policy  Board  Staff  Perspectives  on  Information-Security  Issues 


OTA  note:  This  material  presents  Security  Policy  Board  staff  views  on  information  security  issues  and 
the  SPB  staff  report.  It  was  excerpted  from  SPB  staff  comments  to  OTA  and  has  been  edited  for  length. 

. . .  [T]he  general  area  of  Information  Systems  Security  presents  us  all  with  one  of  the  most  difficult  and 
controversial  aspects  of  security  policy.  Because  of  this,  there  has  been  a  great  deal  of  recent  analysis  and 
activity  in  the  area  of  Information  Systems  Security  policy  involving  the  Security  Policy  Board  (SPB),  the 
Security  Policy  Forum  (SPF),  and  out  supporting  Staff.  Because  of  the  fast  pace  of  recent  events,  and  the 
fact  that  for  the  SPB/SPF,  Information  Systems  Security  policy  is  a  “work  in  progress”  in  its  early  stages,  we 
have  not  done  the  best  job  in  getting  the  word  out  to  the  community  beyond  the  26  agencies  and  depart¬ 
ments  that  are  represented  in  the  SPB  on  the  current  status  of  our  Information  Systems  Security-related 
activities.  [The  OTA  background  paper]  may  provide  an  excellent  vehicle  for  presenting  a  balanced  view  of 
Executive  Branch  analysis  and  activity  in  this  critical  policy  area. 

. . .  The  [section  above  on  information-security  policy  initiatives]  begins  by  accurately  noting  that  net¬ 
work  security  issues  are  of  great  concern,  and  then  suggests  that  DOD  activity  under  the  name  of  “In¬ 
formation  Warfare”  (IW)  is  raising  awareness  of  threats  to  networks,  and  is  contributing  to  the  momentum 
for  consolidating  Information  Systems  Security  authorities  government-wide,  thereby  increasing  the  role  of 
the  defense  and  intelligence  agencies.  While  that  may  be  true  to  some  extent,  the  draft  is  silent  on  other 
reasons  why  there  may  be  a  “momentum"  for  at  least  considering  the  advisability  of  consolidating  some 
aspects  of  government  Information  Systems  Security  policymaking,  e.g.,  the  increasing  internetworking 
across  the  “classified’  and  “unclassified”  communities.  Others  may  argue  that  the  splitting  of  Information 
Systems  Security  responsibilities  by  Public  Law  100-235  simply  isn’t  working  to  provide  the  level  of  sys¬ 
tems  security  both  communities  need— failing  for  many  of  the  same  reasons  the  PDD-24  failed  when  it 
attempted  to  split  Communications  Security  (COMSEC)  authorities  along  similar  lines.  However,  it  is  not  the 
role  of  the  SPB/SPF  Staff  to  take  a  position  on  these  issues,  but  rather  to  act  as  an  “honest  broker”  within 
the  Executive  Branch  to  ensure  that  all  aspects  of  security  policy  receive  an  informed,  balanced  review.  In 
pursuing  this  role,  we  have  recognized  the  relationship  of  defensive  IW  to  Information  Systems  Security 
policy,  but  do  not  see  it  as  the  only,  or  even  the  primary,  driver  of  whatever  momentum  exists  to  consoli¬ 
date  Executive  Branch  Information  Systems  Security  responsibilities.  Many  of  the  issues  surrounding  the 
“consolidation”  question-e.  g.,  efficient  use  of  limited  government  resources— have  no  trace  of  the  De¬ 
fense/Intelligence  flavor  of  DOD  Information  Warfare  activities. . . 

[OTA’S  description]  of  PDD-29  and  its  organization  creations  is  mostly  accurate  although  you  err  in  im¬ 
plying  that  the  structure  is  DOD  and  Intelligence  Community  oriented.  Actually,  quite  the  opposite  is  true.  In 
fact,  if  OTA  were  to  be  challenged  to  develop  a  senior  level  government-wide  board  to  serve  as  a  “fair 
court”  to  adjudicate  information  systems  security  and  other  security  policy  issues,  you  would  quite  likely 
develop  an  entity  very  similar  if  not  the  same  as  the  SPB.  The  majority  of  the  SPB  itself  comes  from  the  civil 
agencies. . .  [T]he  very  important  Security  Policy  Forum  (SPF)  includes  among  its  26  members  the  Depart¬ 
ments  of  Commerce,  Energy,  Justice,  State,  Treasury,  Transportation,  and  representatives  from  OMB,  Na¬ 
tional  Aeronautics  and  Space  Administration,  Nuclear  Regulatory  Commission,  Office  of  Personnel  Man¬ 
agement,  General  Services  Administration,  and  Federal  Emergency  Management  Agency.  Again,  the 
majority  of  the  SPF  membership  is  from  the  civil  agencies.  Quite  frankly,  we  find  it  ironic  that  your  draft 
gives  significant  credence  to  negative  comments  about  the  SPB  efforts  credited  to  representatives  of  Com¬ 
merce  and  the  OMB  when  both  the  Deputy  Secretary  of  Commerce  and  the  Deputy  Director  of  the  OMB  sit 
on  the  SPB  and  have  been  active  participants  in  the  SPB  deliberations  to  date. 
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In  PDD-29,  the  President  observed,  “We  require  a  new  security  process  based  on  sound  threat  analysis 
and  risk  management  practices.  A  process  which  can  adapt  our  security  policies,  practices  and  proce¬ 
dures  as  the  economic,  political  and  military  challenges  to  our  national  interests  continue  to  evolve.”  The 
President  further  charged  the  SPB  to  conduct  a  review  of  ail  of  our  nation’s  security  policies,  practices  and 
procedures  and  make  recommendations  for  needed  change  after  such  proposals  have  been  coordinated 
with  all  US,  departments  and  agencies  affected  by  such  decisions. 

At  the  first  SPB  meeting  on  27  September  1994,  the  SPB  Staff  was  charged  with  starting  a  government¬ 
wide  dialogue  on  the  various  elements  of  security  policy  by  developing  a  “strawman”  proposal.  The  Staff 
attempted  to  start  this  by  publishing  the  “New  Order”  paper,  which  simply  contained  proposals  [emphasis 
in  original]  for  how  the  government  might  more  effectively  address  the  various  security  disciplines,  as  rec¬ 
ommended  by  the  Joint  Security  Commission  (JSC).  Many  of  the  Staff  recommendations  were  “no  brain- 
ers.  ”  In  the  field  of  personnel  security,  for  example,  the  government  had  already  consolidated  its  efforts 
into  one  entity.  In  essence,  the  SPB  Staff  attempted  to  begin  the  dialogue  by  suggesting  the  most  simple 
structure  possible  to  address  government-wide  security  policy.  The  SPB  and  SPF  subsequently  acted  on 
some  of  the  re  sort’s  proposals  and  established  transition  teams  and  committees  for  four  of  the  six  commit¬ 
tees  proposed  in  the  report.  A  fifth  will  be  established  in  mid-May.  However,  recognizing  the  sensitivity  and 
complexity  of  Information  Systems  Security  policy,  the  ISSC  was  not  one  of  the  committees  which  was  es¬ 
tablished,  nor  was  a  transition  team  formed.  Those  who  view  the  establishment  of  the  other  committees  as 
somehow  transforming  the  Staff  Report  into  official  administration  policy  are  mistaken,  and  it  is  unfortunate 
that  so  many  have  chosen  to  misrepresent  the  Staff  Report.  I  can  assure  you  that  the  SPB,  SPF,  and  Staff 
have  not  presented  the  “New  Order”  report  as  anything  other  than  an  early  effort  at  establishing  a  starting 
point  for  serious  dialogue  on  overall  security  policy. 

The  idea  of  an  ISSC  with  government-side  scope  has,  as  fully  expected,  met  with  opposition  from  vari¬ 
ous  parties  for  various  reasons.  It  is  our  goal  to  facilitate  an  informed  discussion  of  the  information  systems 
security  issues  facing  our  nation,  and  to  have  that  informed  discussion  occur  at  the  appropriate  levels 
within  the  government.  Our  review  to  date  has  focused  almost  exclusively  on  the  ever  growing  area  where 
the  classified  community  and  the  unclassified  community  intersect.  Therein  are  any  number  of  government 
owned  systems  which  may  be  considered  critical  to  the  safety  and  security  of  our  nation  and  its  people: 
systems  such  as  the  Federal  Election  System,  air  traffic  control  and  those  that  control  our  nation’s  power 
grid,  for  example.  It  has  generally  been  assumed  that  the  private  sector,  to  the  extent  possible,  will  devel¬ 
op  the  needed  security  for  these  systems.  This  may  be  true,  but  the  question  remains  that  if  an  “Oklahoma 
City”  like  incident  occurs  in  one  or  more  of  these  systems,  who  will  our  nation,  the  Congress,  and  our  Presi¬ 
dent  turn  to.  To  that  end,  we  framed  the  “scope”  issue  for  the  SPF,  which,  in  turn,  raised  the  issue  at  the  24 
April  1995  meeting  of  the  SPB.  The  outcome  of  that  meeting  was  direction  by  the  SPB  to  its  member  agen¬ 
cies  to  attempt  development  of  Terms  of  Reference  for  an  interagency  group  to  study  these  issues  and 
report  back  to  the  SPB.  The  SPB  Staff  has,  therefore,  scheduled  a  meeting  to  begin  that  process  which 
[took]  place  on  4  May  1995.  In  keeping  with  our  efforts  to  be  the  “honest  broker,”  the  Staff  has  invited  all 
member  agencies,  Office  of  Science  and  Technology  Policy  and  other  interested  departments  and  agen¬ 
cies  representing  the  widely  divergent  points  of  view  with  regard  to  this  subject. 

(continued) 
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BOX  1-3  (cont’d.):  Security  Policy  Board  Staff  Perspectives  on  Information-Security  Issues 


In  taking  this  initiative,  the  Deputy  Secretaries  that  comprise  the  SPB  recognize  that  they  may  be  sub¬ 
ject  to  criticism.  However,  their  concerns  about  taking  positive  action  to  avoid  catastrophe  in  any  number 
of  these  critical  systems  was  best  summed  up  when  one  observed,  “Shame  on  us  if  we  don’t  at  least  try!” 

The  SPB,  SPF,  and  Staff  have  not  and  never  will  propose  that  any  information  systems  security  actions 
will  be  taken  which  are  contrary  to  law,  government  regulations,  or  directives.  It  does  not  necessarily  fol¬ 
low,  however,  that  issues  cannot  be  explored,  that  ideas  cannot  be  considered,  or  that  new  approaches  to 
difficult  security  problems  cannot  be  explored  which  are  outside  the  context  of  preexisting  policies,  laws, 
regulations,  and  organizational  structures.  It  is  entirely  possible  that  what  was  appropriate  in  1987  may  not 
be  completely  adequate  in  1995.  Information  technology  has  advanced  manyfold  since  then;  the  National 
Information  Infrastructure  has  developed  and  the  information  systems  security  challenges  facing  the  clas¬ 
sified  and  unclassified  communities  have  become  more  similar,  Indeed,  the  very  reason  for  establishing 
the  JSC  was  to  develop  newapproaches  to  security  that  would  “assure  the  adequacy  of  protection  within 
the  contours  of  a  security  system  that  is  simplified,  more  uniform,  and  more  cost  effective  [emphasis  in 
original],  As  referenced  earlier  in  PDD-29,  the  President  directed  that  “The  SPB  will  be  the  principal  mecha¬ 
nism  for  reviewing  and  proposing  to  the  NSC  legislative  initiatives  and  executive  orders  pertaining  to  U.S. 
security  policy,  procedures,  and  practices. . .“  If  an  informed  dialogue  within  the  government,  across  the 
Executive  and  Legislative  Branches,  leads  to  a  common  sense  view  to  make  Information  Systems  Security 
policy  in  a  manner  different  from  the  way  it  is  currently  done,  then  laws,  policies,  regulations,  and  organiza¬ 
tional  structures  could  certainly  be  adjusted  to  accomplish  national  Information  Systems  Security  goals. 
Again,  it  is  our  role  on  the  SPB/SPF  Staff  to  facilitate  that  informed  dialogue. 

SOURCE.  Excerpted  from  Peter  D.  Saderholm  (Director,  Security  Policy  Board  Staff),  memorandum  to  Joan  D.  Winston  and  Miles 
Ewing  (OTA),  May  4, 1995, 


pabilities,  risks,  and  vulnerabilities  of  the  present 
computing  environment,  as  opposed  to  the  rela¬ 
tively  closed,  centralized  processing  environment 
of  the  past.  Today’s  processing  environment  is 
characterized  by  open,  widely  distributed  in¬ 
formation-processing  systems  that  are  intercon¬ 
nected  with  other  systems  within  and  outside 
government  and  by  an  increasing  dependence  of 
federal  agency  operations  on  these  systems. 
OMB ’s  “federal  information  technology  world” 
encompasses  over  2  million  individual  worksta¬ 
tions  (e.g.,  PCs),  but|oonly  some  25,000  medium 
and  large  computers.  Accordingly,  a  major  fo¬ 
cus  of  OMB’s  new  guidance  is  on  end  users  and 
decentralized  information-processing  systems — 


and  the  information-processing  applications  they 
use  and  support. 

According  to  OMB,  the  proposed  revision  of 
Appendix  III  stresses  management  controls  (such 
as  individual  responsibility,  awareness,  and  train¬ 
ing)  and  accountability,  rather  than  technical  con¬ 
trols.  OMB  also  considers  that  the  proposed 
security  appendix  would  better  integrate  security 
into  agencies’  program  and  mission  goals,  reduce 
the  need  for  centralized  reporting  of  paper  security 
plans,  emphasize  the  management  of  risk  rather 
than  its  measurement,  and  revise  government- 
wide  security  responsibilities  to  be  consistent 
with  the  Computer  Security  Act.109 


Ed  Springer,  OMB,  personal  communication,  Mar.  23,  1995. 
Office  of  Management  and  Budget,  op.  cit.,  footnote  107. 


Chapter  1  Introduction  and  Summary  1 33 


OMB’s  proposed  new  security  appendix: 

. . .  proposes  to  re-orient  the  Federal  computer 
security  program  to  better  respond  to  a  rapidly 
changing  technological  environment.  It  establishes 
government- wide  responsibilities  for  Federal  com¬ 
puter  security  and  requires  Federal  agencies  to 
adopt  a  minimum  set  of  management  controls. 

These  management  controls  are  directed  at  indi¬ 
vidual  information  technology  users  in  order  to  re¬ 
flect  the  distributed  nature  of  today’s  technology. 
For  security  to  be  most  effective,  the  controls  must 
be  a  part  of  day-to-day  operations.  This  is  best  ac¬ 
complished  by  planning  for  security  not  as  a  sepa¬ 
rate  activity,  but  as  part  of  overall  planning. 

“Adequate  security”  is  defined  as  “security 
commensurate  with  the  risk  and  magnitude  of  harm 
from  the  loss,  misuse,  or  unauthorized  access  to  or 
modification  of  information.”  This  definition  ex¬ 
plicitly  emphasizes  the  risk-based  policy  for  cost- 
effective  security  established  by  the  Computer 
Security  Act.110 

The  new  guidance  assigns  the  Security  Policy 
Board  responsibility  for  (only)  “national  security 
policy  coordination  in  accordance  with  the  ap¬ 
propriate  Presidential  directive  [e.g.,  PDD 
29] .” 1 1 1  With  respect  to  national  security  informa¬ 
tion: 

Where  an  agency  processes  information  which 
is  controlled  for  national  security  reasons  pursuant 
to  an  Executive  Order  or  statute,  security  measures 
required  by  appropriate  directives  should  be  in¬ 
cluded  in  agency  systems.  Those  policies,  proce¬ 
dures,  and  practices  will  be  coordinated  with  the 
U.S.  Security  Policy  Board  as  directed  by  the  Presi¬ 
dent.112 

Otherwise,  the  proposed  OMB  guidance  assigns 
government-wide  responsibilities  to  agencies  that 
is  “consistent  with  the  Computer  Security  Act.” 
These  agencies  include  the  Department  of  Com¬ 
merce,  through  NIST;  the  Department  of  Defense, 


through  NSA;  the  Office  of  Personnel  Manage¬ 
ment;  the  General  Services  Administration;  and 
the  Department  of  Justice.113 

A  complete  analysis  of  the  proposed  revision  to 
Appendix  III  is  beyond  the  scope  of  this  back¬ 
ground  paper.  In  brief,  the  proposed  new  guidance 
reflects  a  fundamental  and  necessary  shift  in  em¬ 
phasis  from  securing  automated  information  sys¬ 
tems  to  safeguarding  automated  information 
itself.  It  seeks  to  accomplish  this  through: 

■  controls  for  general  support  systems  (including 
hardware,  software,  information,  data,  applica¬ 
tions,  and  people)  that  share  common  function¬ 
ality  and  are  under  the  same  direct  management 
control;  and 

■  controls  for  major  applications  (that  require 
special  attention  due  to  their  mission-critical 
nature). 

For  each  type  of  control,  OMB  seeks  to  ensure 
managerial  accountability  by  requiring  manage¬ 
ment  officials  to  authorize  in  writing ,  based  on  re¬ 
view  of  implementation  of  the  relevant  security 
plan,  use  of  the  system  or  application.  For  general 
support  systems,  OMB  specifies  that  use  should 
be  re-authorized  at  least  every  three  years.  Simi¬ 
larly,  major  applications  must  be  authorized  be¬ 
fore  operating  and  reauthorized  at  least  every  three 
years  thereafter.  For  major  applications,  manage¬ 
ment  authorization  implies  accepting  the  risk  of 
each  system  used  by  the  application.114 

This  type  of  active  risk  acceptance  and  account¬ 
ability,  coupled  with  review  and  reporting  require¬ 
ments,  is  intended  to  result  in  agencies  ensuring 
that  adequate  resources  are  devoted  to  implement¬ 
ing  “adequate  security.”  Every  three  years  (or 
when  significant  modifications  are  made),  agen¬ 
cies  must  review  security  controls  in  systems  and 
major  applications  and  correct  deficiencies.  De¬ 
pending  on  the  severity,  agencies  must  also  con- 


110  Ibid.,  p.  4. 

111  Ibid.,  p.  15. 

112  Ibid.,  pp.  3-4. 

113  Ibid.,  pp.  14-16. 

114  Ibid.,  pp.  2-6. 
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sider  identifying  a  deficiency  in  controls  pursuant 
to  the  Federal  Manager’s  Financial  Accountabil¬ 
ity  Act.  Agencies  are  required  to  include  a  sum¬ 
mary  of  their  system  security  plans  and  major 
application  security  plans  in  the  five-year  plan  re¬ 
quired  by  the  Paperwork  Reduction  Act. 

IMPLICATIONS  FOR 
CONGRESSIONAL  ACTION 

Appendix  D  of  this  paper,  based  on  chapter  1  of 
the  1994  OTA  report  on  information  security  and 
privacy,  reviews  the  set  of  policy  options  in  that 
report.  OTA  identified  policy  options  related  to 
three  general  policy  areas: 

1.  national  cryptography  policy,  including  feder¬ 
al  information  processing  standards  and  export 
controls; 

2.  guidance  on  safeguarding  unclassified  in¬ 
formation  in  federal  agencies;  and 

3.  legal  issues  and  information  security,  includ¬ 
ing  electronic  commerce,  privacy,  and  intel¬ 
lectual  property. 

In  all,  OTA  identified  about  two  dozen  possible 
options.  The  need  for  openness,  oversight,  and 
public  accountability — given  the  broad  public 
and  business  impacts  of  these  policies — runs 
throughout  the  discussion  of  possible  congres¬ 
sional  actions.  During  its  follow-on  work,  OTA 
found  that  recent  and  ongoing  events  have  rele¬ 
vance  for  congressional  consideration  of  policy 
issues  and  options  identified  in  the  1994  report, 
particularly  in  the  first  two  areas  noted  above. 

In  OTA’s  view,  two  key  questions  underlying 
consideration  of  options  addressing  cryptography 
policy  and  unclassified  information  security  with¬ 
in  the  federal  government  are: 

1.  How  will  we  as  a  nation  develop  and  maintain 
the  balance  among  traditional  “national  securi¬ 
ty”  (and  law  enforcement)  objectives  and  other 
aspects  of  the  public  interest,  such  as  economic 
vitality,  civil  liberties,  and  open  government? 

2.  What  are  the  costs  of  government  efforts  to 
control  cryptography  and  who  will  bear  them? 

Some  of  these  costs — for  example,  the  incremen¬ 
tal  cost  of  requiring  a  “standard”  solution  that  is 


less  cost-effective  than  the  “market”  alternative  in 
meeting  applicable  security  requirements — may 
be  relatively  easy  to  quantify,  compared  with  oth¬ 
ers.  But  none  of  these  cost  estimates  will  be  easy 
to  make.  Some  costs  may  be  extremely  difficult  to 
quantify,  or  even  to  bound — for  example,  the  im¬ 
pact  of  technological  uncertainties,  delays,  and 
regulatory  requirements  on  U.S.  firms’  abilities  to 
compete  effectively  in  the  international  market¬ 
place  for  information  technologies.  Ultimately, 
however,  these  costs  are  all  borne  by  the  public, 
whether  in  the  form  of  taxes,  product  prices,  or 
foregone  economic  opportunities  and  earnings. 

The  remainder  of  this  chapter  discusses  pos¬ 
sible  congressional  actions  related  to  cryptogra¬ 
phy  policy  and  government  information  security, 
in  the  context  of  the  policy  issues  and  options 
OTA  identified  in  the  1994  report.  These  options 
can  be  found  in  appendix  D  of  this  background  pa¬ 
per  and  pp.  16-20  of  the  1994  report.  For  the  read¬ 
er’s  convenience,  the  pertinent  options  are 
discussed  in  boxes  1  -4  through  1  -7  in  this  chapter. 

I  Cryptography  Policy  and 
Export  Controls 

In  the  1994  study  and  its  follow-on  work,  OTA  has 
observed  that  many  of  the  persistent  concerns  sur¬ 
rounding  the  Clinton  Administration’s  escrowed- 
encryption  initiative  focus  on  whether  key-escrow 
encryption  will  become  mandatory  for  govern¬ 
ment  agencies  or  the  private  sector,  if  nones- 
crowed  encryption  will  be  banned,  and/or  if  these 
actions  could  be  taken  without  legislation.  Other 
concerns  still  focus  on  whether  or  not  alternative 
forms  of  encryption  would  be  available  that  would 
allow  private  individuals  and  organizations  the 
option  of  depositing  keys  (or  not)  with  one  or 
more  third-party  trustees — at  their  discretion  (see 
pp.  8-10, 14-18, 171-182of  the  1994  OTA  report). 

Congressional  Review  of 
Cryptography  Policy 

OTA  noted  that  an  important  outcome  of  a  con¬ 
gressional  review  of  national  cryptography  policy 
would  be  the  development  of  more  open  processes 
to  determine  how  cryptography  will  be  deployed 
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BOX  1-4:  Congressional  Review  ol  Cryptography  Policy 


OTA  concluded  that  information  to  support  a  congressional  policy  review  of  cryptography  is  out  of 
phase  with  implementation.  Therefore,  OTA  noted  that: 

OPTION:  Congress  could  consider  placing  a  hold  on  further  deployment  of  key-escrow  encryp¬ 
tion,  pending  a  congressional  policy  review. 

More  open  processes  would  build  trust  and  confidence  in  government  operations  and  leadership.  More 
openness  would  allow  diverse  stakeholders  to  understand  how  their  views  and  concerns  were  being  bal¬ 
anced  with  those  of  others,  in  establishing  an  equitable  deployment  of  these  technologies,  even  when 
some  of  the  specifics  of  the  technology  remain  classified.  More  open  processes  would  also  allow  for  public 
consensus-building,  providing  better  information  for  use  in  congressional  oversight  of  agency  activities. 
Toward  these  ends,  OTA  noted  that: 

OPTION:  Congress  could  address  the  extent  to  which  the  current  working  relationship  between 
the  National  Institute  of  Standards  Technology  and  National  Security  Agency  will  be  a  satisfac¬ 
tory  part  of  this  open  process,  or  the  extent  to  which  the  current  arrangements  should  be  reevalu¬ 
ated  and  revised. 

Another  important  outcome  of  a  broad  policy  review  would  be  a  clarification  of  national  information- 
policy  principles  in  the  face  of  technological  change: 

OPTION:  Congress  could  state  its  policy  as  to  when  the  impacts  of  a  technology  (like  cryptogra¬ 
phy)  are  so  powerful  and  pervasive  that  legislation  is  needed  to  provide  sufficient  public  visibility 
and  accountability  for  government  actions. 

SOURCE:  Office  of  Technology  Assessment,  1995;  based  on  Information  Security  and  Privacy  in  Network  Environments  (OTA* 
TCT-606,  September  1994). 


throughout  society,  including  development  of  the 
public-key  infrastructures  and  certification  autho¬ 
rities  that  will  support  electronic  delivery  of  gov¬ 
ernment  services  and  digital  commerce. 

In  1993,  Congress  asked  the  National  Research 
Council  to  conduct  a  major  study  thu .  would  sup¬ 
port  a  broad  review  of  cryptography  and  ifs  de¬ 
ployment;  the  results  are  expected  to  be  available 
in  1996.  The  NRC  study  should  be  valuable  in 
helping  Congress  to  understand  the  broad  range  of 
technical  and  institutional  alternatives.  However, 
if  implementation  of  the  EES  and  related  technol¬ 
ogies  continues  at  the  current  pace,  OTA  has  noted 
that  key-escrow  encryption  may  already  be  em¬ 
bedded  in  information  systems  before  Congress 
can  act  on  the  NRC  report. 

Therefore,  OTA’s  options  for  congressional 
consideration  (see  box  1-4)  included  an  option  to 
place  a  hold  on  further  deployment  of  escrowed 
encryption  within  the  government,  pending  a  con¬ 
gressional  review,  as  well  as  options  addressing 


open  policy  implementation,  and  public  visibility 
and  accountability.  These  are  still  germane,  espe¬ 
cially  given  the  NSA’s  expectation  of  a  large-scale 
investment  in  FORTEZZA  cards  and  the  likeli¬ 
hood  that  nondefense  agencies  will  be  encouraged 
by  NS  A  to  join  in  adopting  FORTEZZA. 

There  has  been  very  little  information  from  the 
Clinton  Administration  as  to  the  current  and  pro¬ 
jected  costs  of  the  escrowed-encryption  initiative, 
including  costs  of  the  current  escrow  agencies  for 
Clipper  and  Capstone  chips  and  total  expenditures 
anticipated  for  deployment  of  escrowed-encryp¬ 
tion  technologies.  (NSA  has  indicated  that  a  FOR¬ 
TEZZA  procurement  contract  on  the  order  of  $20 
million  to  $40  million  may  be  awarded  in  fall 
1995.) 

Export  Controls 

Reform  of  the  current  export  controls  on  cryptog¬ 
raphy  was  certainly  the  number  one  topic  at  the 
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BOX  1-5:  Export  Controls  on  Cryptography 


As  part  of  a  broad  national  cryptography  policy,  OTA  noted  that  Congress  may  wish  to  periodically  ex¬ 
amine  export  controls  on  cryptography,  to  ensure  that  these  continue  to  reflect  an  appropriate  balance  be¬ 
tween  the  needs  of  signals  intelligence  and  law  enforcement  and  the  needs  of  the  public  and  business 
communities.  This  examination  would  take  into  account  changes  in  foreign  capabilities  and  foreign  avail¬ 
ability  of  cryptographic  technologies. 

Information  from  an  executive  branch  study  of  the  encryption  market  and  export  controls  that  was 
promised  by  Vice  President  Gore  should  provide  some  near-term  information.  The  Department  of  Com¬ 
merce  and  the  National  Security  Agency  (NSA)  are  assessing  the  economic  impact  of  U.S.  export  controls 
on  the  U.S.  computer  software  industry;  as  part  of  this  study,  NSA  is  determining  the  foreign  availability  of 
encryption  products.  The  study  is  scheduled  to  be  delivered  to  the  National  Security  Council  deputies  by 
July  1,  1995. 

OTA  noted  that  the  scope  and  methodology  of  the  export-control  studies  that  Congress  might  wish  to 
use  in  the  future  may  differ  from  those  used  in  the  executive-branch  study.  Therefore: 

OPTION:  Congress  might  wish  to  assess  the  validity  and  effectiveness  of  the  Clinton  Administra¬ 
tion's  studies  of  export  controls  on  cryptography  by  conducting  oversight  hearings ,  by  undertaking 
a  staff  anaiysis,  or  by  requesting  a  study  from  the  Congressional  Budget  Office. 

SOURCE:  Off  Ice  of  Technology  Assessment,  1995:  based  on  Information  Security  and  Privacy  in  Network  Environments  (OTA- 
TCT-606,  September  1994). 


December  1994  OTA  workshop.  More  generally, 
the  private  sector’s  priority  in  this  regard  is  indi¬ 
cated  by  the  discussion  of  the  industry  statements 
of  business  needs  above.  Legislation  would  not  be 
required  to  relax  controls  on  cryptography,  if  this 
were  done  by  revising  the  implementing  regula¬ 
tions.  However,  the  Clinton  Administration  has 
previously  evidenced  a  disinclination  to  relax 
controls  on  robust  cryptography,  except  perhaps 
for  certain  key-escrow  encryption  products."5 

The  Export  Administration  Act  is  to  be  reau¬ 
thorized  in  the  104th  Congress.  The  issue  of  ex¬ 
port  controls  on  cryptography  may  arise  during 
consideration  of  export  legislation,  or  if  new  ex¬ 
port  procedures  for  key-escrow  encryption  prod¬ 
ucts  are  announced,  and/or  when  the  Clinton 
Administration’s  market  study  of  cryptography 
and  controls  is  completed  this  summer  (see  box 
1-5). 


Aside  from  any  consideration  of  whether  or  not 
to  include  cryptography  provisions  in  the  1995  ex¬ 
port  administration  legislation,  Congress  could 
advance  the  convergence  of  government  and  pri¬ 
vate  sector  interests  into  some  “feasible  middle 
ground”  through  hearings,  evaluation  of  the  Clin¬ 
ton  Administration’s  market  study,  and  by  encour¬ 
aging  a  more  timely,  open,  and  productive 
dialogue  between  government  and  the  private  sec¬ 
tor  (see  pages  11-13,  150-160,  174-179  of  the 
1994  OTA  report.) 

Responses  to  Escrowed 
Encryption  Initiatives 

The  1994  OTA  report  recognized  that  Congress 
has  a  near-term  role  to  play  in  determining  the  ex¬ 
tent  to  which — and  how — the  EES  and  other  es¬ 
crowed-encryption  systems  will  be  deployed  in 


mSee  appendix  C  of  this  backgroud  paper,  especially  footnote  10  and  accompanying  text. 
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BOX  1-6:  Congressional  Responses  to  Escrowed-Encryption  Initiatives 


In  responding  to  current  escrowed-encryption  initiatives  like  the  Escrowed  Encryption  Standard  (EES), 
and  in  determining  the  extent  to  which  appropriated  funds  should  be  used  in  implementing  key-escrow 
encryption  and  related  technologies,  OTA  noted  that: 

OPTION:  Congress  could  address  the  appropriate  locations  of  the  key-escrow  agents ,  particularly 
for  federal  agencies,  before  additional  investments  are  made  in  staff  and  faciiities  for  them.  Public 
acceptance  of  key-escrow  encryption  might  be  improved-but  not  assured-by  an  escrowing  system 
that  used  separation  of  powers  to  reduce  perceptions  of  the  potential  for  misuse. 

With  respect  to  current  escrowed-encryption  initiatives  like  the  EES,  as  well  as  any  subsequent  key-es¬ 
crow  encryption  initiatives  (e.g.,  for  data  communications  or  file  encryption),  and  in  determining  the  extent 
to  which  appropriated  funds  should  be  used  in  implementing  key-escrow  encryption  and  related  technolo¬ 
gies,  OTA  noted  that: 

OPTION:  Congress  could  address  the  issue  of  criminal  penalties  for  misuse  and  unauthorized 
disclosure  of  escrowed  key  components. 

OPTION:  Congress  could  consider  allowing  damages  to  be  awarded  for  individuals  or  organiza¬ 
tions  who  were  harmed  by  misuse  or  unauthorized  disclosure  of  escrowed  key  components. 

SOURCE:  Office  of  Technology  Assessment,  1995;  based  on  Information  Security  and  Privacy  in  Network  Environments  (OTA- 
TCT-606,  September  1994). 


the  United  States.  These  actions  can  be  taken 
within  a  long-term,  strategic  framework.  Con¬ 
gressional  oversight  of  the  effectiveness  of  policy 
measures  and  controls  can  allow  Congress  to  re¬ 
visit  these  issues  as  needed,  or  as  the  conse¬ 
quences  of  previous  decisions  become  more 
apparent. 

The  Clinton  Administration  has  stated  that  it 
has  no  plans  to  make  escrowed  encryption  manda¬ 
tory,  or  to  ban  other  forms  of  encryption.  But,  ab¬ 
sent  legislation,  these  intentions  are  not  binding 
for  future  administrations  and  also  leave  open  the 
question  of  what  will  happen  if  the  EES  and  re¬ 
lated  technologies  do  not  prove  acceptable  to  the 
private  sector.  Moreover,  the  executive  branch 
may  soon  be  using  the  EES  and/or  related  es¬ 
crowed-encryption  technologies  (e.g.,  FORTEZ- 
ZA)  to  safeguard-among  other  things — large 
volumes  of  private  and  proprietary  information. 

For  these  reasons,  OTA  concluded  that  the  EES 
and  other  key-escrowing  initiatives  are  by  no 
means  only  an  executive  branch  concern.  The 
EES  and  any  subsequent  escrowed-encryption 
standards  (e.g.,  for  data  communications  in  com¬ 
puter  networks,  or  for  file  encryption)  also  war¬ 


rant  congressional  attention  because  of  the  public 
funds  that  will  be  spent  in  deploying  them.  More¬ 
over,  negative  public  perceptions  of  the  EES  and 
the  processes  by  which  encryption  standards  are 
developed  and  deployed  may  erode  public  confi¬ 
dence  and  trust  in  government  and,  consequently, 
the  effectiveness  of  federal  leadership  in  promot¬ 
ing  responsible  safeguard  use.  Therefore,  OTA 
identified  options  addressing  location  of  escrow 
agents,  as  well  as  criminal  penalties  and  civil  lia¬ 
bilities  for  misuse  or  unauthorized  disclosure  of 
escrowed  key  components  (see  box  1-6).  These 
are  still  germane,  and  the  liability  issues  are  even 
more  timely,  given  recent  initiatives  by  the  in¬ 
ternational  legal  community  and  the  states. 

I  Safeguarding  Unclassified  Information 
in  the  Federal  Agencies 

The  need  for  congressional  oversight  of  federal  in¬ 
formation  security  and  privacy  is  even  more  ur¬ 
gent  in  a  time  of  government  reform  and 
streamlining.  When  the  role,  size,  and  structure  of 
the  federal  agencies  are  being  reexamined,  it  is  im¬ 
portant  to  take  into  account  the  additional  in- 
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formation  security  and  privacy  risks  incurred  in 
downsizing  and  the  general  lack  of  commitment 
on  the  part  of  top  agency  management  to  safe¬ 
guarding  unclassified  information. 

A  major  problem  in  the  agencies  has  been  lack 
of  top  management  focus  oh,  not  to  mention  re¬ 
sponsibility  and  accountability  for,  information 
security.  As  the  1994  OTA  report  noted: 

The  single  most  important  step  toward  imple¬ 
menting  proper  information  safeguards  for  net¬ 
worked  information  in  a  federal  agency  or  other 
organization  is  for  top  management  to  define  the 
organization’s  overall  objectives  and  a  security 
policy  to  reflect  those  objectives.  Only  top  man¬ 
agement  can  consolidate  the  consensus  and  apply 
the  resources  necessary  to  effectively  protect  net¬ 
worked  information.  For  the  federal  government, 
this  means  guidance  from  OMB,  commitment  from 
top  agency  management,  and  oversight  by  Con¬ 
gress.  (p.  7) 

All  too  often,  agency  managers  have  regarded 
information  security  as  “expensive  overhead”  that 
could  be  skimped  on,  deferred,  or  foregone  in  fa¬ 
vor  of  other  expenditures  (e.g.,  for  new  computer 
hardware  and  applications).  Any  lack  of  priority 
and  resources  for  safeguarding  information  is  in¬ 
creasingly  problematic  as  we  move  toward  in¬ 
creased  secondary  use  of  data,  data  sharing  across 
agencies,  and  decentralization  of  information 
processing  and  databases.  If  this  mindset  were 
permitted  to  continue  during  agency  downsizing 
and  program  consolidation,  the  potential — and 
realized — harms  from  “disasters  waiting  to  hap¬ 
pen”  can  be  much  greater.  (See  pages  1-8, 25-31, 
and  40-43  of  the  1994  OTA  report.)  For  example, 
without  proper  attention  to  information  security, 
staffing  changes  during  agency  restructuring  and 
downsizing  can  increase  security  risks  (due  to  un¬ 
staffed  or  understaffed  security  functions,  reduc¬ 
tions  in  security  training  and  implementation, 
large  numbers  of  disgruntled  former  employees, 
etc.). 

OTA’s  ongoing  work  has  spotlighted  important 
elements  of  good  information-security  practice  in 
the  private  sector,  including  active  risk  acceptance 
by  line  management.  The  concept  of  management 
responsibility  and  accountability  as  integral  com¬ 


ponents  of  information  security,  rather  than  just 
“handing  off’  security  to  technology,  is  very  im¬ 
portant. 

Sound  security  policies  as  a  foundation  for 
practice  are  essential;  these  should  be  technology 
neutral.  Technology-neutral  policies  specify  what 
must  be  done,  not  how  to  do  it.  Because  they  do 
not  prescribe  implementations,  technology-neu¬ 
tral  policies  are  longer  lived.  They  are  not  so  easi¬ 
ly  obsoleted  by  changes  in  technology  or  business 
practices;  they  allow  for  local  customization  of 
implementations  to  meet  operational  require¬ 
ments.  Once  these  are  in  place,  security  imple¬ 
mentation  should  be  audited  against  policy,  not 
against  implementation  guidelines.  This  helps 
prevent  confusing  implementation  techniques  and 
tools  (e.g.,  use  of  a  particular  type  of  encryption  or 
use  of  an  computer  operating  system  with  a  certain 
rating)  with  policy  objectives,  and  discourages 
“passive  risk  acceptance”  like  mandating  use  of  a 
particular  technology.  This  also  allows  for  flexi¬ 
bility  and  customization. 

In  the  federal  arena,  however,  more  visible  en¬ 
ergy  seems  to  have  been  focused  on  debates  over 
implementation  tools — that  is,  federal  informa¬ 
tion  processing  standards  like  the  Data  Encryption 
Standard,  Digital  Signature  Standard,  and  Es¬ 
crowed  Encryption  Standard — than  on  formulat¬ 
ing  enduring,  technology-neutral  policy  guidance 
for  the  agencies. 

Direction  of  Revised  OMB  Guidance 

In  the  1994  report,  OTA  identified  the  need  for  the 
revised  version  of  the  security  appendix  (Appen¬ 
dix  III)  of  OMB  Circular  A- 130  to  adequately  ad¬ 
dress  problems  of  managerial  responsibility  and 
accountability,  insufficient  resources  devoted  to 
information  security,  and  overemphasis  on  tech¬ 
nology,  as  opposed  to  management.  In  particular, 
OTA  noted  the  importance  of  making  agency  line 
management  (not  just  “information  security  offi¬ 
cers”)  accountable  for  information  security  and 
ensuring  that  privacy  and  other  policy  objectives 
are  met.  Moreover,  OTA  noted  that  the  proposed 
new  OMB  guidance  would  have  to  provide  suffi¬ 
cient  incentives — especially  in  times  of  budget 
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cuts — to  ensure  that  agencies  devote  adequate  re¬ 
sources  to  safeguarding  information.  Similarly, 
the  OMB  guidance  would  have  to  ensure  that  in¬ 
formation  safeguards  are  treated  as  an  integral 
component  when  systems  are  designed  or  modi¬ 
fied. 

The  proposed  revision  to  Appendix  III  of  OMB 
Circular  A- 130,  as  discussed  above,  shows  prom¬ 
ise  for  meeting  these  objectives.  OMB’s  proposed 
guidance  is  intended  to  incorporate  critical  ele¬ 
ments  of  the  following:  considering  security  as  in¬ 
tegral  (rather  than  an  add-on)  to  planning  and 
operations,  active  risk  acceptance,  line  manage¬ 
ment  responsibility  and  accountability,  and  focus 
on  management  and  people  rather  than  technolo¬ 
gy.  Taken  as  a  whole,  these  elements  are  intended 
to  provide  sufficient  incentives  for  agency  man¬ 
agements  to  devote  adequate  resources  to  securi¬ 
ty;  the  review  and  reporting  requirements  offer 
disincentives  for  inadequate  security.  Moreover, 
if  implemented  properly,  the  new  OMB  approach 
can  make  significant  progress  in  the  ultimate  goal 
of  tracking  and  securing  the  information  itself,  as 
it  is  gathered,  stored,  processed,  and  shared 
among  users  and  applications. 

However,  OMB’s  twofold  approach  is  some¬ 
what  abstract  and  a  significant  departure  from  ear¬ 
lier,  “computer  security”  guidance.  Therefore, 
congressional  review  and  oversight  of  OMB’s 
proposed  revisions  to  Appendix  III,  as  suggested 
in  the  1994  OTA  report  (see  box  1-7),  would  be 
helpful  in  ensuring  that  Congress,  as  well  as  feder¬ 
al  agencies  and  the  public,  understand  the  new  in¬ 
formation-security  guidance  and  how  OMB 
intends  for  its  new  approach  to  be  implemented. 

This  congressional  review  and  oversight  might 
also  provide  additional  guidance  on  how  NIST’s 
security  activities  might  best  be  refocused  to  meet 
federal  information-security  objectives.  For  ex¬ 
ample,  in  addition  to  Commerce’s  (i.e.,  NIST’s) 
traditional  responsibilities  for  security  standards 
and  training  and  awareness,  the  new  Appendix  III 
assigns  Commerce  responsibilities  for  providing 


agencies  with  guidance  and  assistance  concerning 
effective  controls  when  systems  are  intercon¬ 
nected,  coordinating  incident  response  activities 
to  promote  information-sharing  regarding  inci¬ 
dents  and  related  vulnerabilities,  and  (with  De¬ 
fense  Department  technical  assistance)  evaluating 
new  information  technologies  to  assess  their  secu¬ 
rity  vulnerabilities  and  apprising  agencies  of  these 
in  a  timely  fashion.116 

Locus  of  Authority 

Another  reason  for  the  importance  and  timeliness 
of  congressional  oversight  of  governmentwide  in¬ 
formation-security  policy  guidance  is  that  there  is 
renewed  momentum  for  extending  the  defense/in¬ 
telligence  community’s  centralization  of  informa¬ 
tion-security  responsibilities  throughout  the  civil 
agencies  as  well.  If  initiatives  such  as  the  Informa¬ 
tion  Systems  Security  Committee  structure  pres¬ 
ented  in  the  Security  Policy  Board  staff  report 
come  to  fruition,  information-security  responsibi¬ 
lities  for  both  the  civilian  agencies  and  the  de¬ 
fense/intelligence  agencies  would  be  merged. 

An  overarching  issue  that  must  be  resolved  by 
Congress  is  where  federal  authority  for  safeguard¬ 
ing  unclassified  information  in  the  civilian  agen¬ 
cies  should  reside  and,  therefore,  what  needs  to  be 
done  concerning  the  substance  and  implementa¬ 
tion  of  the  Computer  Security  Act  of  1 987.  If  Con¬ 
gress  retains  the  general  premise  of  the  act — that 
responsibility  for  unclassified  information  securi¬ 
ty  in  the  civilian  agencies  should  not  be  placed 
within  the  defense/intelligence  community — then 
vigilant  oversight  and  clear  direction  will  be  need¬ 
ed  to  ensure  effective  implementation,  including 
assigning  and  funding  a  credible  focal  point(s)  for 
unclassified  information  security  (see  discussion 
of  OMB  Appendix  III  above  and  also  pp.  19-20  of 
the  1994  OTA  report). 

Without  doubt,  leadership  and  expertise  are 
needed  for  better,  more  consistent  safeguarding  of 
unclassified  information  government-wide.  But  it 


116  OMB,  op.  cit.,  footnote  82,  p.  7. 
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BOX  1-7:  Safeguarding  Information  in  Federal  Agencies 


Congress  has  an  even  more  direct  role  in  establishing  the  policy  guidance  within  which  federal  agen¬ 
cies  safeguard  information,  and  in  oversight  of  agency  and  Office  of  Management  and  Budget  measures  to 
implement  information  security  and  privacy  requirements.  The  new,  proposed  revision  of  Appendix  III  (“Se¬ 
curity  of  Federal  Automated  Information”)  of  OMB  Circular  A-130  is  intended  to  lead  to  improved  federal 
information-security  practices  and  to  make  fulfillment  of  Computer  Security  Act  and  Privacy  Act  require¬ 
ments  more  effective  generally,  as  well  as  with  respect  to  data  sharing  and  secondary  uses. 

The  options  presented  below  are  in  the  context  of  the  1994  report  and  the  previous  version  of  Appendix 
III.  However,  OTA  expects  that  congressional  oversight  and  analysis  as  indicated  below  will  remain  useful 
for  understanding  OMB’s  new  guidance  and  assessing  its  potential  effectiveness.  OTA  noted  that,  after  the 
revised  Appendix  III  of  OMB  Circular  A-130  issued: 

OPTION:  Congress  could  assess  the  effectiveness  of  the  OMB’s  revised  guidelines,  including  im¬ 
provements  in  implementing  the  Computer  Security  Act’s  provisions  regarding  agency  security 
plans  and  training,  in  order  to  determine  whether  additional  statutory  requirements  or  oversight 
measures  are  needed. 

This  might  be  accomplished  by  conducting  oversight  hearings,  undertaking  a  staff  analysis,  and/or  re¬ 
questing  a  study  from  the  General  Accounting  Office.  However,  the  effects  of  OMB’s  revised  guidance  may 
not  be  apparent  for  some  time  after  the  revised  Appendix  III  is  issued. 

Therefore,  a  few  years  may  pass  before  GAO  is  able  to  report  government-wide  findings  that  would  be 
the  basis  for  determining  the  need  for  further  revision  or  legislation.  In  the  interim: 

OPTION:  Congress  could  gain  additional  insight  through  hearings  to  gauge  the  reaction  of  agen¬ 
cies,  as  well  as  privacy  and  security  experts  from  outside  government,  to  OMB’s  revised  guidelines. 

Oversight  of  this  sort  might  be  especially  valuable  for  agencies  that  are  developing  major  new  informa¬ 
tion  systems,  in  the  course  of  its  oversight  and  when  considering  the  direction  of  any  new  legislation,  OTA 
noted  that: 

OPTION:  Congress  could  ensure  that  agencies  include  explicit  provisions  for  safeguarding  in¬ 
formation  assets  in  any  information-technology  planning  documents. 


is  not  clear  that  there  are  no  workable  alternatives 
to  centralizing  government-wide  information-se¬ 
curity  responsibilities  under  the  defense/intelli¬ 
gence  community.  Proposals  to  do  so  note  current 
information-security  deficiencies;  however,  many 
of  these  can  be  attributed  to  lack  of  commitment  to 
and  funding  for  establishment  of  an  alternative 
source  of  expertise  and  technical  guidance  for  the 
civilian  agencies.  For  example,  the  “efficiency” 
arguments  (see  below)  made  in  the  Joint  Security 
Commission  report  and  the  Security  Policy  Board 
staff  report  for  extending  the  responsibilities  of 
the  defense/intelligence  community  to  encompass 
government-wide  security  for  classified  and  un¬ 
classified  information  capitalize  on  the  vacuum  in 
leadership  and  expertise  created  by  chronic  un¬ 


derfunding  of  the  designated  civilian  agency — at 
present,  NIST.  (See  pp.  13-16,  20,  138-150,  and 
182-183  of  the  OTA  report.) 

Proposals  for  centralizing  security  responsibi¬ 
lities  for  both  classified  and  unclassified  informa¬ 
tion  government-wide  offer  efficiency  arguments 
to  the  effect  that: 

1.  security  policies,  practices,  and  procedures  (as 
well  as  technologies)  for  unclassified  informa¬ 
tion  are  for  the  most  part  spin-offs  from  the 
classified  domain; 

2.  the  defense  and  intelligence  agencies  are  expert 
in  classified  information  security;  and  there¬ 
fore 
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OPTION:  Congress  could  ensure  that  agencies  budget  sufficient  resources  to  safeguard  informa¬ 
tion  assets,  whether  as  a  percentage  of  information-technology  modernization  and/or  operating 
budgets,  or  otherwise. 

OPTION:  Congress  could  ensure  that  the  Department  of  Commerce  assigns  sufficient  resources 
to  the  National  Institute  of  Standards  and  Technology  to  support  its  Computer  Security  Act  respon¬ 
sibilities,  as  well  as  NET’S  other  activities  related  to  safeguarding  information  and  protecting  priva¬ 
cy  in  networks. 

Regarding  NIST’s  computer-security  budget,  OTA  did  not  determined  the  extent  to  which  additional 
funding  is  needed,  or  the  extent  to  which  additional  funding  would  improve  the  overall  effectiveness  of 
NEST's  information-security  activities.  Additional  resources,  whether  from  overall  increases  in  NIST’s  budget 
or  otherwise,  could  enhance  NIST’s  technical  capabilities,  enable  it  to  be  more  proactive,  and  hence  be 
more  useful  to  federal  agencies  and  to  industry.  OTA  found  that  NIST  activities  regarding  standards  and 
guidelines  related  to  jryptography  are  a  special  case,  however. 

Increased  funding  alone  will  not  be  sufficient  to  ensure  NIST’s  technological  leadership  or  its  fulfillment 
of  the  “balancing”  role  as  envisioned  by  the  Computer  Security  Act  of  1 987.  With  respect  to  cryptography, 
OTA  concluded  that  national  security  constraints  set  forth  in  executive  branch  policy  directives  appear  to 
be  binding.  These  constraints  have  resulted,  for  example,  in  the  closed  processes  by  which  the  FIPS 
known  as  the  Escrowed  Encryption  Standard  (Clipper)  was  developed  and  implemented. 

Increased  funding  could  enable  NIST  to  become  a  more  equal  partner  to  the  National  Security  Agency, 
at  least  in  deploying  (if  not  developing)  cryptographic  standards.  But,  if  NIST/NSA  processes  and  out¬ 
comes  are  to  reflect  a  different  balance  of  national  security  and  other  public  interests,  or  more  openness, 
than  has  been  evidenced  over  the  past  five  years,  OTA  concluded  that  clear  policy  guidance  and  oversight 
(not  just  funding)  will  be  needed. 

SOURCE”  Office  of  Technology  Assessment,  1995;  based  on  Information  Security  and  Privacy  in  Network  Environments  (OTA- 
TCT-606,  September  1994). 


3.  the  unclassified  domain  can  best  be  served  by 
extending  the  authority  of  the  defense/intelli- 
gence  agencies. 

The  validity  of  the  “spin-off’  assumption  about 
unclassified  information  security  is  questionable. 
There  are  real  questions  about  NSA’s  ability  to 
place  the  right  emphasis  on  cost-effectiveness,  as 
opposed  to  absolute  effectiveness,  in  flexibly  de¬ 
termining  the  most  appropriate  means  for  safe¬ 
guarding  unclassified  information.  Due  to  its 
primary  mission  in  securing  classified  informa¬ 
tion,  NSA’s  traditional  culture  tends  toward  a 
standard  of  absolute  effectiveness,  not  trading  off 
cost  and  effectiveness.  By  contrast,  the  Computer 


Security  Act  of  1987,  the  Paperwork  Reduction 
Act  of  1995,  and  the  new,  proposed  revision  of 
OMB  Appendix  111  all  require  agencies  to  identify 
and  employ  cost-effective  safeguards,  for  ex¬ 
ample: 

With  respect  to  privacy  and  security,  the  Direc¬ 
tor  [of  OMB]  shall .  .  .  require  Federal  agencies, 
consistent  with  the  Computer  Security  Act  of  1987 
(940  U.S.C.  759  note)  security  protections  com¬ 
mensurate  with  the  risk  and  magnitude  of  the  harm 
resulting  from  the  loss,  misuse,  or  unauthorized  ac¬ 
cess  to  or  modification  of  information  collected  or 
maintained  by  or  on  behalf  of  an  agency."' 


"“Paperwork  Reduction  Act  of  1995”  (S.  244),  section  3504(g)(3),  Mar7,  1995,  Federal  Record, p.  S3557. 
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Moreover,  the  current  state  of  government  securi¬ 
ty  practice  for  unclassified  information  has  been 
depressed  by  the  chronic  shortage  of  resources  for 
NIST’s  computer  security  activities  in  fulfillment 
of  its  government-wide  responsibilities  under  the 
Computer  Security  Act  of  1987.  Since  enactment 
of  the  Computer  Security  Act,  there  has  been  no 
serious  (i.e.,  adequately  funded  and  properly 
staffed),  sustained  effort  to  establish  a  center  of  in¬ 
formation-security  expertise  and  leadership  out¬ 
side  the  defense/intelligence  communities. 

Even  if  the  efficiency  argument  is  attractive, 
Congress  would  still  need  to  consider  whether  the 
gains  would  be  sufficient  to  overcome  the  con¬ 
comitant  decrease  in  “openness”  in  information- 
security  policymaking  and  implementation, 
and/or  whether  the  outcomes  would  fall  at  an  ac¬ 
ceptable  point  along  the  “efficiency-openness” 
possibility  frontier.  In  the  area  of  export  controls 
on  cryptography,  for  example,  there  is  substantial 
public  concern  with  the  current  tradeoff  between 
the  needs  of  the  defense/intelligence  and  the  busi¬ 
ness/user  communities.  With  respect  to  informa¬ 
tion-security  standards  and  guidelines,  there  has 
been  continuing  concern  with  the  lack  of  openness 
and  accountability  in  policies  formulated  and  im¬ 
plemented  under  executive  order,  rather  than 
through  the  legislative  process.  It  would  be  diffi¬ 
cult  to  formulate  a  scenario  in  which  increasing 
the  defense/intelligence  community’s  authority 
government-wide  would  result  in  more  openness 
or  assuage  public  concerns.  (In  the  1980s,  con¬ 
cerns  over  NSDD-145’s  placement  of  govern¬ 
mental  authority  for  unclassified  information 


security  within  the  defense/intelligence  commu¬ 
nity  led  to  enactment  of  the  Computer  Security 
Act  of  1987.) 

Oversight  of  the  implementation  of  the  Comput¬ 
er  Security  Act  is  also  important  to  cryptography 
policy  considerations.  The  cryptography-related 
FIPS  still  influence  the  overall  market  and  the  de¬ 
velopment  of  recent  FIPS  (e.g.,  the  DSS  and  EES) 
demonstrates  a  mismatch  between  the  intent  of  the 
act  and  its  implementation  by  NIST  and  NSA  (see 
pp.  160-183  of  the  1994  OTA  report).  The  attrib¬ 
utes  of  these  standards  do  not  meet  most  users’ 
needs,  and  their  deployment  would  benefit  from 
congressional  oversight,  both  in  the  strategic  con¬ 
text  of  a  policy  review  and  as  tactical  response  to 
the  Clinton  Administration’s  escrowed-encryp¬ 
tion  initiative  (see  pp.  16-20  of  the  OTA  report). 

If  the  Computer  Security  Act  is  revisited,  Con¬ 
gress  might  wish  to  redirect  NIST’s  activities 
away  from  “picking  technologies”  for  standards 
(i.e.,  away  from  developing  product-oriented 
FIPS  like  the  EES)  and  toward  providing  federal 
agencies  with  guidance  on: 

■  the  availability  of  suitable  commercial  technol¬ 
ogies, 

■  interoperability  and  application  portability,  and 

■  how  to  make  best  use  of  existing  hardware  and 

software  technology  investments. 

Also,  targeting  NIST’s  information-security  acti¬ 
vities  toward  support  of  OMB  ’s  proposed  guid¬ 
ance  (with  its  focus  on  end  users  and  individual 
workstations)  might  enable  NIST  to  be  more  ef¬ 
fective  despite  scarce  resources. 


Overview  of  the 
1994  OTA  Report 
on  Information 
Security 
and  Privacy 


This  chapter  highlights  the  importance  of  information  secu¬ 
rity  and  privacy  issues,  explains  why  cryptography  poli¬ 
cies  are  so  important,  and  reviews  policy  findings  and 
options  from  the  September  1994  OTA  report  Informa¬ 
tion  Security  and  Privacy  in  Network  Environments.  Chapter  3  re¬ 
views  the  December  1994  OTA  workshop  and  identifies  key 
points  that  emerged  from  the  workshop  discussion,  particularly 
export  controls  and  the  international  business  environment,  fed¬ 
eral  cryptography  policy,  and  information-security  “best  prac¬ 
tices.”  Chapter  4  presents  implications  for  congressional  action, 
in  light  of  recent  and  ongoing  events. 

This  background  paper  is  a  companion  and  supplement  to  the 
September  1994  OTA  report  and  is  intended  to  be  used  in  con¬ 
junction  with  that  report.  For  the  reader’s  convenience,  however, 
pertinent  technical  and  institutional  background  material,  drawn 
from  the  September  1994  report  and  updated  where  appropriate, 
is  included  in  appendices  B  (“Federal  Information  Security  and 
the  .Computer  Security  Act”),  C  (“U.S.  Export  Controls  on  Cryp¬ 
tography”),  and  D  (“Summary  of  Issues  and  Options  from  the 
1994  OTA  Report”). 

INFORMATION  SECURITY  AND  PRIVACY 
IN  A  NETWORKED  SOCIETY 

Information  technologies  are  transforming  the  ways  in  which  we 
create,  gather,  process,  and  share  information.  Rapid  growth  in 
computer  networking  is  driving  many  of  these  changes;  electron¬ 
ic  transactions  and  electronic  records  are  becoming  central  to  ev¬ 
erything  from  business  to  health  care.  Government  connectivity 
is  also  growing  rapidly  in  scope  and  importance.  Within  the  feder- 
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al  government,  effective  use  of  information 
technologies  and  networks  is  central  to  govern¬ 
ment  restructuring  and  reform.1 

The  transformation  being  brought  about  by  net¬ 
working  brings  with  it  new  concerns  for  the  secu¬ 
rity  of  networked  information  and  for  our  ability 
to  maintain  effective  privacy  protections  in  net¬ 
worked  environments.2  Unless  these  concerns  can 
be  resolved,  they  threaten  to  limit  networking’s 
full  potential  in  terms  of  both  participation  and 
usefulness.  Therefore,  information  safeguards 
(countermeasures)  are  achieving  new  promi¬ 
nence.3  Appropriate  safeguards  for  the  networked 
environment  must  account  for — and  anticipate — 
technical,  institutional,  and  social  changes  that  in¬ 
creasingly  shift  responsibility  for  security  to  the 
end  users. 

Computing  power  used  to  be  isolated  in  large 
mainframe  computers  located  in  special  facilities; 
computer  system  administration  was  centralized 
and  carried  out  by  specialists.  In  today’s  net¬ 
worked  environment,  computing  power  is  de¬ 
centralized  to  diverse  users  who  operate  desktop 
computers  and  who  may  have  access  to  comput¬ 
ing  power  and  data  at  remote  locations.  Distrib¬ 
uted  computing  and  open  systems  can  make  every 
user  essentially  an  “insider.”  In  such  a  decentral¬ 


ized  environment,  responsibility  for  safeguarding 
information  is  distributed  to  the  users,  rather  than 
remaining  the  purview  of  system  specialists.  The 
increase  in  the  number  and  variety  of  network  ser¬ 
vice  providers  also  requires  that  users  take  respon¬ 
sibility  for  safeguarding  information,  rather  than 
relying  on  intermediaries  to  provide  adequate 
protection.4 

The  new  focus  is  on  safeguarding  the  informa¬ 
tion  itself  as  it  is  processed,  stored,  and  trans¬ 
mitted.  This  contrasts  with  older,  more  static  or 
insulated  concepts  of  “document”  security  or 
“computer”  security.  In  the  networked  environ¬ 
ment,  we  need  appropriate  rules  for  handling 
proprietary,  copyrighted,  and  personal  informa¬ 
tion — and  tools  with  which  to  implement  them.5 
Increased  interactivity  means  that  we  must  also 
deal  with  transactional  privacy,  as  well  as  prevent 
fraud  in  electronic  commerce  and  ensure  that  safe¬ 
guards  are  integrated  as  organizations  streamline 
their  operations  and  modernize  their  information 
systems. 

REVIEW  OF  THE  1994  OTA  REPORT 

In  September  1994,  the  Office  of  Technology  As¬ 
sessment  released  the  report  Information  Security 


1  See  U.S.  Congress,  Office  of  Technology  Assessment,  Making  Government  Work:  Electronic  Delivery  of  Government  Services ,  OTA- 
TCT-578  (Washington,  DC:  U.S.  Government  Printing  Office,  September  1993).  See  also  Elena  Varon,  “Senate  Panel  Takes  up  IT  Management 
Issues,”  Federal  Computer  Week ,  Feb.  6, 1995,  p.  6;  and  Charles  A.  Bowsher,  Comptroller  General  of  the  United  States,  “Government  Reform: 
Using  Reengineering  and  Technology  To  Improve  Government  Performance,”  GAO/T-OCG-95-2,  testimony  presented  before  the  Committee 
on  Governmental  Affairs,  U.S.  Senate,  Feb.  2,  1995. 

2  For  example,  measures  to  streamline  operations  via  information  technology  require  careful  attention  both  to  technical  safeguards  and  to 
related  institutional  measures,  such  as  employee  training  and  awareness.  Similarly,  computer  networks  allow  more  interactivity,  but  the  result¬ 
ing  transactional  data  may  require  additional  safeguards  to  protect  personal  privacy. 

3  See  Michael  Neubarth  et  al.,  “Internet  Security  (Special  Section),”  Internet  World ,  February  1995,  pp.  31-72.  See  also  Russell  Mitchell, 
“The  Key  to  Safe  Business  on  the  Net,”  and  Amy  Cortese  et  al.,  “Warding  Off  the  Cyberspace  Invaders,”  Business  Week,  Mar.  13, 1995,  pp.  86, 
92-93. 

4  The  trend  is  toward  decentralized,  distributed  computing,  rather  than  centralized,  mainframe  computing.  Distributed  computing  is  rela¬ 
tively  informal  and  “bottom  up  ”  compared  with  mainframe  computing,  and  systems  administration  may  be  less  rigorous.  See  U.S.  Congress, 
Office  of  Technology  Assessment,  Information  Security  and  Privacy  in  Network  Environments,  OTA-TCT-606  (Washington,  DC:  U.S.  Govern¬ 
ment  Printing  Office,  September  1994),  pp.  3-5, 25-32.  Available  from  OTA  Online  via  anonymous  file  transfer  protocol  (ftp://otabbs.ota.gov/ 
pub/information. security/)  or  World  Wide  Web  (http://www.ota.gov). 

5  See  ibid.,  chapter  3.  “Security”  technologies  like  encryption  can  be  used  to  help  protect  privacy  and  the  confidentiality  of  proprietary 
information;  some,  like  digital  signatures,  could  be  used  to  facilitate  copyright-management  systems. 
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and  Privacy  in  Network  Environments ,6  The  re¬ 
port  was  prepared  in  response  to  a  request  by  the 
Senate  Committee  on  Governmental  Affairs  and 
the  House  Subcommittee  on  Telecommunications 
and  Finance  that  OTA  study  the  changing  needs 
for  protecting  unclassified  information  and  for 
protecting  the  privacy  of  individuals.7  The  request 
for  the  study  was  motivated  by  the  rapid  increase 
in  connectivity  within  and  outside  government 
and  the  growth  in  federal  support  for  large-scale 
networks.  The  report  focused  on  safeguarding  in¬ 
formation  in  networks,  not  on  the  security  or  sur¬ 
vivability  of  the  networks  themselves,  nor  on  the 
reliability  of  network  services  to  ensure  informa¬ 
tion  access. 

The  report  identified  policy  issues  and  options  in 
three  areas:  1)  cryptography  policy,  including  fed¬ 
eral  information  processing  standards  and  export 
controls;  2)  guidance  on  safeguarding  unclassi¬ 
fied  information  in  federal  agencies;  and  3)  legal 
issues  and  information  security,  including  elec¬ 
tronic  commerce,  privacy,  and  intellectual  proper¬ 
ty.  The  report  concluded  that  Congress  has  a  vital 
role  in  formulating  national  cryptography  policy 
and  in  determining  how  we  safeguard  information 
and  protect  personal  privacy  in  an  increasingly 
networked  society  (see  outline  of  policy  issues 
and  options  in  the  last  section  of  this  chapter  and 
the  expanded  discussion  in  appendix  D). 

I  Importance  of  Cryptography 

Cryptography  (see  box  2-1)  and  related  federal 
policies  (e.g.,  regarding  export  controls  and  stan¬ 


dards  development)  were  a  major  focus  of  the  re¬ 
port.8  That  focus  was  due  in  part  from  the 
widespread  attention  being  given  the  so-called 
Clipper  chip  and  the  Clinton  Administration’s  es¬ 
crowed-encryption  initiative.  Escrowed  encryp¬ 
tion,  or  key-escrow  encryption,  refers  to  a 
cryptosystem  in  which  the  functional  equivalent 
of  a  “spare  key”  must  be  deposited  with  a  third 
party,  in  order  to  ensure  easy  access  to  decryption 
keys  pursuant  to  lawful  electronic  surveillance. 
The  Clinton  Administration’s  escrowed-encryp¬ 
tion  initiative,  first  announced  in  1993,  required 
the  “spare  keys”  to  be  held  within  the  executive 
branch.  The  Escrowed  Encryption  Standard 
(EES),  promulgated  as  a  federal  information  proc¬ 
essing  standard  (FIPS)  in  1994,  is  approved  for 
use  in  encrypting  unclassified  voice,  fax,  or  data 
communicated  in  a  telephone  system.9 

However,  a  focus  on  cryptography  was  inevita¬ 
ble,  because  in  its  modem  setting,  cryptography 
has  become  a  fundamental  technology  with  broad 
applications.  Modem,  computer-based  cryptogra¬ 
phy  and  cryptanalysis  began  in  the  World  War  II 
era.10  Much  of  this  development  has  been 
shrouded  in  secrecy;  in  the  United  States,  govern¬ 
mental  cryptographic  research  has  historically 
been  the  purview  of  the  “national  security”  (i.e., 
defense  and  intelligence)  communities.11 

Now,  however,  cryptography  is  a  technology 
whose  time  has  come — in  the  marketplace  and  in 
society.  Cryptography  is  not  arcane  anymore.  De¬ 
spite  two  decades  of  growth  in  nongovernmental 
research  and  development,  in  the  United  States, 


6  Ibid. 

7  Ibid.,  pp.  5-6  and  appendix  A  (congressional  letters  of  request). 

8  Ibid.,  pp.  8-18  and  chapter  4. 

9  The  EES  is  implemented  in  hardware  containing  the  Clipper  chip.  The  EES  (FIPS- 1 85)  specifies  use  of  a  classified,  symmetric  encryption 
algorithm,  called  “Skipjack,”  which  was  developed  by  the  National  Security  Agency.  The  “Capstone  chip”  implements  the  Skipjack  algorithm 
for  use  in  computer  network  applications.  The  Defense  Department’s  “FORTEZZA  card”  (a  PCMCIA  card  formerly  called  TESSERA  )  con¬ 
tains  the  Capstone  chip. 

10  See,  e.g.,  David  Kahn,  The  Codebreakers  (New  York,  NY:  MacMillan,  1967). 

H  Although  there  has  always  been  some  level  of  nongovernmental  cryptography  research  in  the  United  States,  from  the  end  of  WWII 
through  the  mid-1970s  the  federal  government  was  almost  the  sole  U.S.  source  of  technology  and  know-how  for  modern  cryptographic  safe¬ 
guards.  The  government’s  former  near-monopoly  in  development  and  use  of  cryptography  has  been  eroding,  however. 
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BOX  2-1:  Cryptograph 


During  the  long  history  of  paper-based  “information  systems”  for  commerce  and  communication,  a  num¬ 
ber  of  safeguards  were  developed  to  ensure  the  confidentiality,  integrity,  and  authenticity  of  documents  and 
messages.  These  traditional  safeguards  included  secret  codebooks  and  passwords,  physical  “seals”  to  au¬ 
thenticate  signatures,  and  auditable  bookkeeping  procedures.  Mathematical  analogues  of  these  safeguards 
are  implemented  in  the  electronic  environment.  The  most  powerful  of  these  are  based  on  cryptography. 

The  recorded  history  of  cryptography  is  more  than  4,000  years  old,  Manual  encryption  methods  using 
codebooks,  letter  and  number  substitutions,  and  transpositions  have  been  used  for  hundreds  of  years— for 
example,  the  Library  of  Congress  has  letters  from  Thomas  Jefferson  to  James  Madison  containing  en¬ 
crypted  passages.  Modern,  computer-based  cryptography  and  cryptanalysts  began  in  the  World  War  II 
era,  with  the  successful  Allied  computational  efforts  to  break  the  ciphers  generated  by  the  German  Enigma 
machines,  and  with  the  British  Colossus  computing  machines  used  to  analyze  a  crucial  cipher  used  in  the 
most  sensitive  German  teletype  messages. 

In  the  post-WWII  era,  the  premiere  locus  of  U.S.  cryptographic  research  and  (especially)  research  in 
cryptanalysts  has  been  the  Defense  Department’s  National  Security  Agency  (NSA).  NSA's  preeminent  posi¬ 
tion  results  from  its  extensive  role  in  U.S.  signals  intelligence  and  in  securing  classified  communications, 
and  the  resulting  need  to  understand  cryptography  as  a  tool  to  protect  information  and  as  a  tool  used  by 
adversaries. 

In  its  modern  setting,  cryptography  is  a  field  of  applied  mathematics/computer  science.  Cryptographic 
algorithms— specific  techniques  for  transforming  the  original  input  into  a  form  that  is  unintelligible  without 
special  knowledge  of  some  secret  (closely  held)  information— are  used  to  encrypt  and  decrypt  messages, 
data,  or  other  text.  The  encrypted  text  is  often  referred  to  as  ciphertext;  the  original  or  decrypted  text  is 
often  referred  to  as  plaintext  or  cleartext.  In  modern  cryptography,  the  secret  information  is  the  crypto¬ 
graphic  key  that  “unlocks”  the  ciphertext  and  reveals  the  plaintext. 

The  encryption  algorithms  and  key  or  keys  are  implemented  in  a  cryptosystem.  The  key  used  to  de¬ 
crypt  can  be  the  same  as  the  one  used  to  encrypt  the  original  plaintext,  or  the  encryption  and  decryption 
keys  can  be  different  (but  mathematically  related),  One  key  is  used  for  both  encryption  and  decryption  in 
symmetric,  or“conventional”  cryptosystems;  in  asymmetric,  or  “public-key”  cryptosystems,  the  encryption 


the  federal  government  still  does  have  the  most 
expertise  in  cryptography.  Nevertheless,  cryptog¬ 
raphy  is  not  just  a  “government”  technology  any¬ 
more,  either.  Because  it  is  a  technology  of  broad 
application,  the  effects  of  federal  policies  about 
cryptography  are  not  limited  to  technological  de¬ 
velopments  in  the  field,  or  even  to  the  health  and 
vitality  of  companies  that  produce  or  use  products 
incorporating  cryptography.  Instead,  these  poli¬ 
cies  will  increasingly  affect  the  everyday  lives  of 
most  Americans. 

Encryption  (see  box  2-2)  transforms  a  message 
or  data  files  (called  “plaintext”)  into  a  form  (called 
“ciphertext”)  that  is  unintelligible  without  special 
knowledge  of  some  secret  information  (called  the 
“decryption  key”).  Figures  2-1  and  2-2  illustrate 


two  common  forms  of  encryption:  1)  secret-key, 
or  symmetric,  encryption  and  2)  public-key,  or 
asymmetric,  encryption.  Note  that  key  manage¬ 
ment — the  generation  of  encryption  and  decryp¬ 
tion  keys,  as  well  as  their  storage,  distribution, 
cataloging,  and  eventual  destruction-is  crucial 
for  the  overall  security  of  any  encryption  system. 
In  some  cases  (e.g.,  for  archival  records),  when 
files  or  databases  are  encrypted,  the  keys  have  to 
remain  cataloged  and  stored  for  very  long  periods 
of  time. 

Encryption  can  be  used  as  a  tool  to  protect  the 
confidentiality  of  information  in  messages  or 
files-hence,  to  help  protect  personal  privacy. 
Other  applications  of  cryptography  can  be  used  to 
protect  the  integrity  of  information  (that  it  has  not 
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BOX  2-1  (cont'd.):  Cryptography 


and  decryption  keys  are  different  and  one  of  them  can  be  made  public.  With  the  advent  of  “public-key” 
techniques,  cryptography  also  came  into  use  for  digital  signatures  that  are  of  widespread  interest  as  a 
means  for  electronically  authenticating  and  signing  commercial  transactions  like  purchase  orders,  tax  re¬ 
turns,  and  funds  transfers,  as  well  as  ensuring  that  unauthorized  changes  or  errors  are  detected. 

Cryptanalysis  is  the  study  and  development  of  various  “codebreaking”  methods  to  deduce  the  contents  of 
the  original  plaintext  message.  The  strength  of  an  encryption  algorithm  is  a  function  of  the  number  of  steps, 
storage,  and  time  required  to  break  the  cipher  and  read  any  encrypted  message,  without  prior  knowledge  of 
the  key.  Mathematical  advances,  advances  in  cryptanalysts,  and  advances  in  computing,  all  can  reduce  the 
security  afforded  by  a  cryptosystem  that  was  previously  considered  “unbreakable"  in  practice. 

The  strength  of  a  modern  encryption  scheme  is  determined  by  the  algorithm  itself  and  the  length  of  the 
key,  For  a  given  algorithm,  strength  increases  with  key  size.  However,  key  size  alone  is  a  not  a  valid  means 
of  comparing  the  strength  of  tv,r>  differer  ‘  encryption  systems.  Differences  in  the  properties  of  the  algo¬ 
rithms  may  mean  that  a  system  using  a  shorter  key  is  stronger  overall  than  one  using  a  longer  key. 

Key  management  is  fundamental  and  crucial  to  the  security  afforded  by  any  cryptography-based  safe¬ 
guard.  Key  management  includes  generation  of  the  encryption  key  or  keys,  as  well  as  their  storage,  dis¬ 
tribution,  cataloging,  and  eventual  destruction.  If  secret  keys  are  not  closely  held,  the  result  is  the  same  as 
if  a  physical  key  is  left  “lying  around”  to  be  stolen  or  duplicated  without  the  owner's  knowledge.  Similarly, 
poorly  chosen  keys  may  offer  no  more  security  than  a  lock  that  can  be  opened  with  a  hairpin.  Changing 
keys  frequently  can  limit  the  amount  of  information  or  the  number  of  transactions  compromised  due  to  un¬ 
authorized  access  to  a  given  key.  Thus,  a  well-thought-out  and  secure  key-management  infrastructure  is 
necessary  for  effective  use  of  encryption-based  safeguards  in  network  environments.  Such  a  support  infra¬ 
structure  might  include  means  for  issuing  keys  and/or  means  for  registering  users'  public  keys  and  linking 
owner-registration  certificates  to  keys  so  that  the  authenticity  of  digital  signatures  can  be  verified.  This 
might  be  done  by  a  certificate  authority  as  part  of  a  public-key  infrastructure. 

SOURCE:  Office  of  Technology  Assessment,  1 995;  drawing  from  OTA,  Information  Security  and  Privacy  in  Network  Environments 
(OTA-TCT-606,  September  1994),  pp,  112-113  and  sources  cited  therein. 


been  subject  to  unauthorized  or  unexpected 
changes)  and  to  authenticate  its  origin  (that  it 
comes  from  the  stated  source  or  origin  and  is  not  a 
forgery). 

Thus,  cryptography  is  a  technology  that  will 
help  speed  the  way  to  electronic  commerce.  With 
the  advent  of  what  are  called  public-key  tech¬ 
niques,  cryptography  came  into  use  for  digital  sig¬ 
natures  (see  figure  2-3)  that  are  of  widespread 
interest  as  a  means  for  electronically  authenticat¬ 


ing  and  signing  commercial  transactions  like  pur¬ 
chase  orders,  tax  returns,  and  funds  transfers,  as 
well  as  for  ensuring  that  unauthorized  changes  or 
errors  are  detected  (see  discussion  of  message  au¬ 
thentication  and  digital  signatures  in  box  2-2). 12 
These  functions  are  critical  for  electronic  com¬ 
merce.  Cryptographic  techniques  like  digital 
signatures  can  also  be  used  to  help  manage  copy¬ 
righted  material  in  electronic  form.  13 


l!OTA,  op.  cit.,  footnote  4,  pp.  69-77.  See  also  Lisa  Morgan.  “Cashing  In:  The  Rush  Is  on  To  Make  Net  Commerce  Happen,”  Internet  World, 
February  1995,  pp.  48-51;  and  Richard  W.  Wiggirts,  “Business  Browser:  A  Tool  To  Make  Web  Commerce  Secure,"  Internet  World,  February 
1995,  pp.  52-55. 

“OTA,  ibid.,  pp.  96-  1 10.  For  example,  digital  signatures  can  be  used  to  create  compact  “copyright  tokens”  for  use  in  registries;  encryption 
could  be  used  to  create  personalized  “copyright  envelopes"  for  direct  electronic  delivery  of  material  to  customers.  See  also  Working  Group  on 
Intellectual  Property  Rights,  I1TF,  “Intellectual  Property  and  the  National  Information  Infrastructure  (Green  Paper),"  July  1994,  pp.  139-140. 
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BOX  2-2:  Encryption,  Authentication,  and  Digital  Signatures 


Different  cryptographic  methods  are  used  to  authenticate  users,  protect  confidentiality,  and  assure  in¬ 
tegrity  of  messages  and  files.  Most  systems  use  a  combination  of  techniques  to  fulfill  these  functions. 

Encryption 

Cryptographic  algorithms  are  either  symmetric  or  asymmetric ,  depending  on  whether  or  not  the  same 
cryptographic  key  is  used  for  encryption  and  decryption.  The  key  is  a  sequence  of  symbols  that  deter¬ 
mines  the  transformation  from  unencrypted  plaintext  to  encrypted  ciphertext,  and  vice  versa. 

“Symmetric”  cryptosystems— also  called  secret-key  or  single-key  systems— use  the  same  key  to  en¬ 
crypt  and  decrypt  messages.  Both  the  sending  and  receiving  parties  must  know  the  secret  key  that  they 
will  use  to  communicate  (see  figure  2-1  in  the  main  text).  Secret-key  algorithms  can  encrypt  and  decrypt 
relatively  quickly,  but  systems  that  use  only  secret  keys  can  be  difficult  to  manage  because  they  require  a 
courier,  registered  mail,  or  other  secure  means  for  distributing  keys.  The  federal  Data  Encryption  Standard 
(DES)  and  the  new  Escrowed  Encryption  Standard  (EES)  each  use  a  different  secret-key  algorithm. 

“Asymmetric”  cryptosystems— also  called  public-key  systems— use  one  key  to  encrypt  and  a  different, 
but  mathematically  related,  public  key  to  decrypt  messages  (see  figure  2-2).  For  example,  if  an  associate 
sends  Carol  a  message  encrypted  with  Carol’s  public  key,  in  principle  only  Carol  can  decrypt  it,  because 
she  is  the  only  one  with  the  correct  private  key  This  provides  confidentiality  and  can  be  used  to  distribute 
secret  keys,  which  can  then  be  used  to  encrypt  messages  using  a  faster,  symmetric  cryptosystem  (see 
figure  2-3). 

The  security  of  public-key  systems  rests  on  the  authenticity  of  the  public  key  (that  it  is  a  valid  key  for 
the  stated  individual  or  organization,  not  “recalled”  by  the  owner  or  presented  by  an  impostor)  and  the 
secrecy  of  the  private  key,  much  as  the  security  of  symmetric  ciphers  rests  on  the  secrecy  of  the  single 
key.  Although  the  public  key  can  be  freely  distributed,  or  posted  in  the  equivalent  of  a  telephone  directory, 
its  authenticity  must  be  assured  (e.g.,  by  a  certificate  authority  as  part  of  a  public-key  infrastructure). 

Commonly  used  public-key  systems  encrypt  relatively  slowly,  but  are  useful  for  digital  signatures  and 
for  exchanging  the  session  keys  that  are  used  for  encryption  with  a  faster,  symmetric  cryptosystem.  The 
Rivest-Shamir-Adleman  (RSA)  algorithm  is  a  well-known,  commercial  public-key  algorithm. 

Authentication 

The  oldest  and  simplest  forms  of  message  authentication  use  “secret”  authentication  parameters  known 
only  to  the  sender  and  intended  recipient  to  generate  “message  authentication  codes.  ”  So  long  as  the  se¬ 
cret  authentication  parameter  is  kept  secret  from  all  other  parties,  these  techniques  protect  the  sender  and 
the  receiver  from  alteration  or  forgery  of  a  message  by  all  such  third  parties.  Because  the  same  secret 
information  is  used  by  the  sender  to  generate  the  message  authentication  code  and  by  the  receiver  to 
validate  it,  these  techniques  cannot  settle  “disputes”  between  the  sender  and  receiver  as  to  what  mes¬ 
sage,  if  any,  was  sent.  For  example,  message  authentication  codes  could  not  settle  a  dispute  between  a 
stockbroker  and  client  in  which  the  broker  claims  the  client  issued  an  order  to  purchase  stock  and  the 
client  claims  he  never  did  so. 

For  authentication,  if  a  hypothetical  user  (Carol)  uses  her  private  key  to  sign  messages,  her  associates 
can  verify  her  signature  using  her  public  key.  This  method  authenticates  the  sender,  and  can  be  used  with 
hashing  functions  (see  below)  for  a  digital  signature  that  can  also  check  the  integrity  of  the  message. 

Digital  Signatures 

Digital  signatures  provide  a  higher  degree  of  authentication  by  allowing  resolution  of  disputes.  Although 
it  is  possible  to  generate  digital  signatures  from  a  symmetric  cipher  like  the  DES,  most  interest  centers  on 
signature  systems  based  on  public-key  cryptosystems. 
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In  principle,  to  sign  a  message  using  a  public-key  encryption  system,  a  user  could  transform  it  with  his 
private  key,  and  send  both  the  original  message  and  the  transformed  version  to  the  intended  receiver.  The 
receiver  would  validate  the  message  by  acting  on  the  transformed  message  with  the  sender’s  public  key 
(obtained  from  the  “electronic  phone  book")  and  seeing  that  the  result  matched  the  original  message.  Be¬ 
cause  the  signing  operation  depends  on  the  sender’s  private  key  (known  only  to  him  or  her),  it  is  impossi¬ 
ble  for  anyone  else  to  sign  messages  in  the  sender’s  name.  But  everyone  can  validate  such  signed  mes¬ 
sages,  since  the  validation  depends  only  on  the  sender’s  “public”  key. 

In  practice,  digital  signatures  sign  shorter  “message  digests”  rather  than  the  whole  messages.  In  most 
public-key  signature  techniques,  a  one-way  hash  function  is  used  to  produce  a  condensed  version  of  the 
message,  which  is  then  “signed.  ”  For  example,  Carol  processes  her  message  with  a  ‘(hashing  algorithm” 
that  produces  a  shorter  messaae  digest— the  equivalent  of  a  very  long  checksum.  Because  the  hashing 
method  is  a  “one-way”  function,  the  message  digest  cannot  be  reversed  to  obtain  the  message.  Bob  also 
processes  the  received  text  with  the  hashing  algorithm  and  compares  the  resulting  message  digest  with 
the  one  Carol  signed  and  sent  along  with  the  message.  If  the  message  was  altered  in  any  way  during 
transit,  the  digests  will  be  different,  revealing  the  alteration  (see  figure  2-4). 

Signature  Alternatives 

With  the  commercial  RSA  system,  the  signature  is  created  by  encrypting  the  message  digest,  using  the 
sender’s  private  key.  Because  in  the  RSA  system  each  key  is  the  inverse  of  the  other,  the  recipient  can  use 
the  sender’s  public  key  to  decrypt  the  signature,  thereby  recovering  the  original  message  digest.  The  re¬ 
cipient  compares  this  with  the  one  he  or  she  has  calculated  using  the  same  hashing  function  if  they  are 
identical,  then  the  message  has  been  received  exactly  as  sent  and,  furthermore,  the  message  did  come 
from  the  supposed  sender  (otherwise  his  or  her  public  key  would  not  have  yielded  the  correct  message 
digest). 

The  federal  Digital  Signature  Standard  (DSS)  defines  a  somewhat  different  kind  of  public-key  crypto¬ 
graphic  standard  for  generating  and  verifying  digital  signatures.  The  DSS  is  to  be  used  in  conjunction  with 
a  federal  hashing  standard  that  is  used  to  create  a  message  digest,  as  described  above.  The  message 
digest  is  then  used,  in  conjunction  with  the  sender’s  private  key  and  the  algorithm  specified  in  the  DSS,  to 
produce  a  message-specific  signature.  Verifying  the  DSS  signature  involves  a  mathematical  operation  on 
the  signature  and  message  digest,  using  the  sender’s  public  key  and  the  hash  standard. 

The  DSS  differs  from  the  RSA  digital  signature  method  in  that  the  DSS  signature  operation  is  not  revers¬ 
ible,  and  hence  can  only  be  used  for  generating  digital  signatures.  DSS  signature  verification  is  different 
than  decryption.  In  contrast,  the  RSA  system  can  encrypt,  as  well  as  do  signatures.  Therefore,  the  RSA 
system  can  also  be  used  to  securely  exchange  cryptographic  keys  that  are  to  be  used  for  confidentiality 
(e.g.,  “secret”  keys  for  use  with  a  symmetric  encryption  algorithm  like  the  DES).  This  lack  of  encryption 
capability  for  secure  key  exchange  was  one  reason  why  the  government  selected  the  DSS  technique  for 
the  standard. 

SOURCE:  Office  of  Technology  Assessment,  1995;  drawing  from  OTA,  Information  Security  and  Privacy  in  Network  Environments 
(OTA-TCT-606,  September  1994),  pp.  39  and  124-125  and  sources  cited  therein  See  also  U.S.  Department  of  Commerce,  National 
Institute  of  Standards  and  Technology,  “Data  Encryption  Standard  (DES),  ”  FIPS  Publication  46-2,  Dec  30, 1993;  “Digital  Signature 
Standard  (DSS),”  FIPS  Publication  186,  May  19, 1994;  and  “Escrowed  Encryption  Standard  (EES), "  FIPS  Publication  185,  February 
1994. 
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FIGURE  2-1:  Secret-Key  (Symmetric)  Encryption 


Carol  encrypts 
her  messages  to 
Ted  with  their 
shared  secret  key 


Ted  decrypts 
messages  from 
Carol  with  the 
same  secret  key 


Carol 


Ted 


Carol  decrypts 
Ted’s  messages 
with  the  same 
secret  key 


Ted  sends 
messages  back 
to  Carol  using 
their  secret  key 


NOTE:  Security  depends  on  the  secrecy  of  the  shared  key. 
SOURCE:  Office  of  Technology  Assessment,  1994. 


The  nongovernmental  markets  for  cryptogra¬ 
phy-based  safeguards  have  grown  over  the  past 
two  decades,  but  are  still  developing.  Good  com¬ 
mercial  encryption  technology  is  available  in  the 
United  States  and  abroad.  Research  in  cryptogra¬ 
phy  is  international.  Absent  government  regula¬ 
tions,  markets  for  cryptography  would  also  be 
international.  However,  export  controls  create 


“domestic”  and  “export”  markets  for  strong  en¬ 
cryption  products  (see  section  on  export  controls 
below  and  also  appendix  C.l4User-friendly  cryp¬ 
tographic  safeguards  that  are  integrated  into  prod¬ 
ucts  (as  opposed  to  those  that  the  user  has  to 
acquire  separately  and  add  on)  are  still  hard  to 
come  by — in  part,  because  of  export  controls  and 
other  federal  policies  that  seek  to  control  cryptog¬ 
raphy.15 

I  Government  Efforts  To 
Control  Cryptography 
In  its  activities  as  a  developer,  user,  and  regulator 
of  safeguard  technologies,  the  federal  government 
faces  a  fundamental  tension  between  two  policy 
objectives,  each  of  which  is  important:  1)  fos¬ 
tering  the  development  and  widespread  use  of 
cost-effective  information  safeguards,  and  2)  con¬ 
trolling  the  proliferation  of  safeguard  technolo¬ 
gies  that  can  impair  U.S.  signals-intelligence  and 
law  enforcement  capabilities.  Cryptography  is  at 
the  heart  of  this  tension.  Export  controls  and  the 
federal  standards  process  (i.e.,  the  development 
and  promulgation  of  federal  information  process¬ 
ing  standards,  or  FIPS)  are  two  mechanisms  the 
government  can  use  to  control  cryptography.16 

Policy  debate  over  cryptography  used  to  be  as 
arcane  as  the  technology  itself.  Even  five  or  10 
years  ago,  few  people  saw  a  link  between  govern¬ 
ment  decisions  about  cryptography  and  their  daily 
lives.  However,  as  the  information  and  commu¬ 
nications  technologies  used  in  daily  life  have 
changed,  concern  over  the  implications  of  policies 
traditionally  dominated  by  national  security  ob¬ 
jectives  has  grown  dramatically. 

Previously,  control  of  the  availability  and  use  of 
cryptography  was  presented  as  a  national  security 
issue  focused  outward,  with  the  intention  of  main¬ 
taining  a  U.S.  technological  lead  over  other  coun¬ 
tries  and  preventing  encryption  devices  from 


“OTA,  ibid.,  pp.  11-13,  150-160. 

15  Ibid.,  pp.  115-123,  128-132,  154-160. 

'‘For  more  detail,  see  ibid.,  chapters  1  and  4,  and  appendix  C.  Other  means  of  control  have  historically  included  include  national  security 
classification  and  patent-secrecy  orders  (see  ibid.,  p.  128  and  footnote  33). 
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FIGURE  2-2:  Public-Key  (Asymmetric)  Encryption 
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NOTE:  Security  depends  on  the  secrecy  of  the  private  keys  and  the  authenticity  of  the  public  keys. 
SOURCE:  Office  of  Technology  Assessment,  1994 
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FIGURE  2-3:  Example  of  a  Hashing  and  Digital  Signature  Scheme 
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NOTE:  Different  methods  for  generating  and  verifying  signatures  (as  in  the  federal  Digital  Signature  Standard)  are  possible.  Measures  to  protect  the 
signature  and  text  may  also  be  used. 

SOURCE:  Office  of  Technology  Assessment,  1994 


falling  into  the  “wrong  hands”  overseas.  More 
widespread  foreign  use — including  use  of  strong 
encryption  by  terrorists  and  developing  coun¬ 
tries — makes  U.S.  signals  intelligence  more  dif¬ 
ficult. 

Now,  with  an  increasing  policy  focus  on  domes¬ 
tic  crime  and  terrorism,  the  availability  and  use  of 
cryptography  has  also  come  into  prominence  as  a 
domestic-security,  law  enforcement  issue.  Within 
the  United  States,  strong  encryption  is  increasing¬ 


ly  portrayed  as  a  threat  to  domestic  security  (pub¬ 
lic  safety)  and  a  barrier  to  law  enforcement  if  it  is 
readily  available  for  use  by  terrorists  or  criminals. 
There  is  also  growing  recognition  of  potentials  for 
misuse,  such  as  by  disgruntled  employees  as  a 
means  to  sabotage  an  employer’s  databases.  Thus, 
export  controls,  intended  to  restrict  the  intern¬ 
ational  availability  of  U.S.  cryptography  technolo¬ 
gy  and  products,  are  now  being  joined  with 
domestic  cryptography  initiatives,  like  key-es- 
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crow  encryption,  that  are  intended  to  preserve 
U.S.  law  enforcement  and  signals-intelligence  ca¬ 
pabilities  (see  box  2-3). 

Standards-development  and  export-control  is¬ 
sues  underlie  a  long  history  of  concern  over  lead¬ 
ership  and  responsibility  (i.e.,  “who  should  be  in 
charge?"  and  “who  is  in  charge?")  for  the  secu¬ 
rity  of  unclassified  information  government- 
wide.17  Most  recently,  these  concerns  have  been 
revitalized  by  proposals  (presented  by  the  Clinton 
Administration’s  Security  Policy  Board  staff)  to 
centralize  information-security  authorities  gov¬ 
ernment-wide  under  joint  control  of  the  Office  of 
Management  and  Budget  (OMB)  and  Department 
of  Defense  (DOD)  (see  discussion  in  chapter  4). 18 

Other  manifestations  of  these  concerns  can  be 
found  in  the  history  of  the  Computer  Security  Act 
of  1987  (Public  Law  100-235 — see  the  next  sec¬ 
tion  and  appendix  B)  and  in  more  recent  develop¬ 
ments,  such  as  public  reactions  to  the  Clinton 
Administration’s  key-escrow  encryption  initia¬ 
tive  and  the  controversial  issuances  of  the  Es¬ 
crowed  Encryption  Standard19  and  Digital 
Signature  Standard  (DSS)20  as  federal  informa¬ 
tion  processing  standards.  Another  important 
manifestation  of  these  concerns  is  the  controversy 
over  the  present  U.S.  export  control  regime, 
which  includes  commercial  products  with  capa¬ 
bilities  for  strong  encryption,  including  mass- 
market  software,  on  the  Munitions  List,  under 
State  Department  controls  (see  below  and  appen¬ 
dix  C). 


The  Escrowed  Encryption  Standard  has  been 
promulgated  by  the  Clinton  Administration  as  a 
voluntary  federal  encryption  standard  (i.e.,  a  vol¬ 
untary,  rather  than  mandatory,  FIPS).  The  EES  an¬ 
nouncement  noted  that  the  standard  does  not 
mandate  the  use  of  escrowed-encryption  devices 
by  government  agencies  or  the  private  sector;  the 
standard  provides  a  mechanism  for  agencies  to  use 
key-escrow  encryption  without  having  to  waive 
the  requirements  of  another,  extant  federal  en¬ 
cryption  standard  for  unclassified  information, 
the  Data  Encryption  Standard  (DES).21 

The  EES  is  intended  for  use  in  encrypting 
unclassified  voice,  facsimile,  and  computer  in¬ 
formation  communicated  over  a  telephone  sys¬ 
tem.  The  encryption  algorithm  (called  Skipjack) 
specified  in  the  EES  can  also  be  implemented  for 
data  communications  in  computer  networks.  At 
this  writing,  there  is  no  FIPS  specifying  use  of 
Skipjack  as  a  standard  algorithm  for  data  commu¬ 
nications  or  file  encryption. 

However,  DOD  is  using  Skipjack  for  encryption 
in  computer  networks  (e.g.,  in  the  “FORTEZZA” 
PCMCIA  card).  As  of  April  1995,  according  to 
the  National  Security  Agency  (NSA),  approxi¬ 
mately  3,000  FORTEZZA  cards  have  been  pro¬ 
duced  and  another  33,000  are  on  contract;  some 
100  to  200  are  being  tested  and  used  in  applica¬ 
tions  development  by  various  DOD  organiza¬ 
tions,  mostly  in  support  of  the  Defense  Message 
System.22  According  to  the  NSA,  plans  call  for 


17  Ibid.,  pp.  8-20  and  chapter  4. 

18  U.S.  Security  Policy  Board  Staff,  “Creating  a  New  Order  in  U.S.  Security  Policy,”  Nov.  21,  1994,  pp.  II-III,  14-18. 

19  See  box  2-3  and  OTA,  op.  cit.,  footnote  4,  ch.  4. 

20  See  box  2-2  and  OTA,  ibid.,  appendix  C. 

21  See  Federal  Register \  vol.  59,  Feb.  9,  1994,  pp.  5997-6005  (“Approval  of  Federal  Information  Processing  Standards  Publication  185, 
Escrowed  Encryption  Standard  (EES)”),  especially  p.  5998.  Note,  however,  that  the  DES  is  approved  for  encryption  of  unclassified  data  com¬ 
munications  and  files,  while  the  EES  is  only  a  standard  for  telephone  communications  at  this  time. 

22  Bob  Drake,  Legislative  Affairs  Office,  NSA,  personal  communication,  Apr.  7,  1995. 
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BOX  2-3:  The  Escrowed  Encryption  Standard 


The  federal  Escrowed  Encryption  Standard  (EES)  was  approved  by  the  Commerce  Department  as  a 
federal  information  processing  standard  (FIPS)  in  February  1994.' According  to  the  standard  (described  in 
FIPS  PUB  185),  the  EES  is  intended  for  voluntary  use  by  all  federal  departments  and  agencies  and  their 
contractors  to  protect  unclassified  information.  Implementations  of  the  EES  are  subject  to  State  Department 
export  controls.  In  1994,  however,  the  Clinton  Administration  indicated  that  encryption  products  based  on 
the  EES  would  be  exportable  to  most  end  users  and  that  EES  products  will  qualify  for  special  licensing 
arrangements.2 

The  National  Security  Council,  Justice  Department,  Commerce  Department,  and  other  federal  agencies 
were  involved  in  the  decision  to  propose  the  EES,  according  to  a  White  House  press  release  and  informa¬ 
tion  packet  dated  April  16,  1993,  the  day  the  EES  initiative  was  announced.  The  EES  algorithm  is  said  to  be 
stronger  than  the  Data  Encryption  Standard  (DES)  algorithm,  but  able  to  meet  the  legitimate  needs  of  law 
enforcement  agencies  to  protect  against  terrorists,  drug  dealers,  and  organized  crime.3 

EES  Functions 

The  EES  is  intended  to  encrypt  voice,  fax,  and  computer  data  communicated  in  a  telephone  system.  It 
may,  on  a  voluntary  basis,  be  used  to  replace  DES  encryption  devices  now  in  use  by  federal  agencies  and 
contractors.  Other  use  by  the  private  sector  is  voluntary.  The  EES  specifies  a  symmetric  encryption  algo¬ 
rithm,  called  “Skip  jack.”  The  Skipjack  algorithm  is  a  classified  algorithm,  developed  by  the  National  Securi¬ 
ty  Agency  (NSA)  in  the  1980s.4 An  early  implementation  was  called  Clipper,  hence  the  colloquial  use  of 
Clipper  or  Clipper  Chip  to  describe  the  EES  technology.5 

The  EES  also  specifies  a  method  to  create  a  Law  Enforcement  Access  Field  (LEAF),  in  order  to  provide 
for  easy  decryption  when  the  equivalent  of  a  wiretap  has  been  authorized.'The  Skipjack  algorithm  and 
LEAF  creation  method  are  implemented  only  in  electronic  devices  (i.e.,  very-large-scale  integration  chips). 
The  chips  are  “highly  resistant”  to  reverse  engineering  and  will  be  embedded  in  tamper-resistant  crypto¬ 
graphic  modules  that  approved  manufacturers  can  incorporate  in  telecommunications  or  computer  equip¬ 
ment.  The  chips  are  manufactured  by  VLSI  Logic  and  are  programmed  with  the  algorithms  and  keys  by 
Mykotronx.  The  programming  is  done  under  the  supervision  of  the  two  “escrow  agents”  (see  below). 


’See  Federal  Register,  vol.  59,  Feb.  9,  1994,  pp.  5997-6005. 

’Martha  Harris,  Deputy  Assistant  Secretary  of  State  for  Political-Military  Affairs,  “Statement  on  Encryption-Export  Control  Re¬ 
form,  ”  Feb.  4, 1994  [OTA  note  The  anticipated  reforms  had  not  all  materialized  as  of  this  writing.] 

’Because  the  EES  algorithm  is  classified,  the  overall  strength  of  the  EES  cannot  be  examined  except  under  security  clearance 
(see  below).  Thus,  unclassified,  public  analyses  of  its  strengths  and  weaknesses  are  not  possible.  The  only  public  statements  made 
by  the  Clinton  Administration  concerning  the  strength  of  the  EES  relative  to  the  DES  refer  to  the  secret-key  size:  80  bits  for  the  EES 
versus  56  bits  for  the  DES 

‘The  NSA  specifications  for  Skipjack  and  the  LEAF  creation  method  are  classified  at  the  Secret  level.  (OTA  project  staff  did  not 
access  these,  or  any  other  classified  information.) 

The  Clipper  Chip  implementation  of  Skipjack  is  for  use  in  secure  telephone  communications.  An  enhanced  escrowed-encryption 
chip  with  additional  functions,  called  Capstone,  is  used  in  data  communications.  Capstone  is  in  the  FORTEZZA  PCMCIA  card  being 
used  in  the  Defense  Message  System 

‘See  Jo  Ann  Harris,  Assistant  Attorney  General,  Criminal  Division,  Department  of  Justice,  testimony  before  the  Subcommittee  on 
Technology  and  the  Law,  Committee  on  the  Judiciary,  U.S.  Senate,  May  3,  1994;  and  James  K.  Kallstrom,  Special  Agent  in  Charge, 
Special  Operations  Division,  Federal  Bureau  of  Investigation,  testimony  before  the  Subcommittee  on  Technology,  Environment,  and 
Aviation,  Committee  on  Science,  Space,  and  Technology,  U.S.  House  of  Representatives,  May  3, 1994  For  a  discussion  of  law  en¬ 
forcement  concerns  and  the  rationale  for  government  key  escrowing,  see  also  Dorothy  E.  Denning,  The  Clipper  Encryption  System,  ” 
American  Scientist,  vol.  81,  July-August  1993,  pp.  319-322;  and  “Encryption  and  Law  Enforcement, "  Feb.  21,  1994,  available  from 
denning@cs.georgetown.edu 
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BOX  2-3  (cortt’d.):  The  Escrowed  Encryption  Standard 


After  electronic  surveillance  has  been  authorized,  the  EES  facilitates  law  enforcement  access  to  en¬ 
crypted  communications.  This  is  accomplished  through  what  is  called  a  “key  escrowing”  scheme.  Each 
EES  chip  has  a  chip-specific  key  that  is  split  into  two  parts  after  being  programmed  into  the  chips.  These 
parts  can  be  recombined  to  gain  access  to  encrypted  communications.  One  part  is  held  by  each  of  two 
designated  government  keyholders,  or  “escrow  agents.”  Attorney  General  Reno  designated  the  National 
Institute  of  Standards  and  Technology  (NIST)  and  the  Treasury  Department’s  Automated  Systems  Division 
as  the  original  escrow  agents.  The  only  public  estimate  (by  NIST,  in  early  1994)  of  the  costs  of  establishing 
the  escrow  system  was  about  $14  million,  with  estimated  annual  operating  costs  of$16  million. 

When  surveillance  has  been  authorized  and  the  intercepted  communications  are  found  to  be  encrypted 
using  the  EES,  law  enforcement  agencies  can  obtain  the  two  parts  of  the  escrowed  key  from  the  escrow 
agents.  These  parts  can  then  be  used  to  obtain  the  individual  keys  used  to  encrypt  (and,  thus,  to  decrypt) 
the  telecommunications  sessions  of  interest.7The  LEAF  is  transmitted  along  with  the  encrypted  message;  it 
contains  a  device  identifier  that  indicates  which  escrowed  keys  are  needed. 

EES  History 

The  proposed  FIPS  was  announced  in  the  Federal  Register  on  July  30,  1993,  and  was  also  sent  to  fed¬ 
eral  agencies  for  review.  The  EES  was  promulgated  after  a  comment  period  that  generated  almost  univer¬ 
sally  negative  comments.  According  to  NIST,  comments  were  received  from  22  government  organizations 
in  the  United  States,  22  industry  organizations,  and  276  individuals.  Concerns  and  questions  reported  by 
NIST  include  the  algorithm  itself  and  lack  of  public  inspection  and  testing,  the  role  of  NSA  in  promulgating 
the  standard,  use  of  key  escrowing,  possible  infringement  of  individual  rights,  effects  of  the  standard  on 
U.S.  firms’  competitiveness  in  foreign  markets,  cost  of  establishing  the  escrowing  system,  and  cost-effec¬ 
tiveness  of  the  new  standard! 

During  the  review  period,  the  Skipjack  algorithm  was  evaluated  by  outside  experts,  pursuant  to  Presi¬ 
dent  Clinton’s  direction  that  “respected  experts  from  outside  the  government  will  be  offered  access  to  the 
confidential  details  of  the  algorithm  to  assess  its  capabilities  and  publicly  report  their  findings.  ”  Five  re¬ 
viewers  accepted  NIST’s  invitation  to  participate  in  a  classified  review  of  Skipjack  and  publicly  report  their 
findings:  Ernest  Brickell  (Sandia  National  Laboratories),  Dorothy  Denning  (Georgetown  University),  Ste¬ 
phen  Kent  (Bolt  Beranek  and  Newman,  Inc.),  David  Maher  (AT&T),  and  Walter  Tuchman  (Amperif  Corp.). 
Their  interim  report  on  the  algorithm  itself  found  that:  1)  there  is  no  significant  risk  that  Skipjack  will  be 
broken  by  exhaustive  search  in  the  next  30  to  40  years;  2)  there  is  no  significant  risk  that  Skipjack  can  be 
broken  through  a  shortcut  method  of  attack;  and  3)  while  the  internal  structure  of  Skipjack  must  be  classi¬ 
fied  in  order  to  protect  law  enforcement  and  national  security  objectives,  the  strength  of  Skipjack  against  a 
cryptanalytic  attack  does  not  depend  on  the  secrecy  of  the  algorithm.9 


7  Requirements  for  federal  and  state  law  enforcement  agents  to  certify  that  electronic  surveillance  has  been  authorized,  and  for 
what  period  of  time,  as  well  as  requirements  for  authorized  use  of  escrowed  key  components  are  explained  in  Department  of  Justice, 
“Authorization  Procedures  for  Release  of  Encryption  Key  Components  in  Conjunction  with  Intercepts  Pursuant  to  Title  III, "  "Authoriza¬ 
tion  Procedures  for  Release  of  Encryption  Key  Components  in  Conjunction  with  Intercepts  Pursuant  to  State  Statutes,  ”  and  “Authoriza¬ 
tion  Procedures  for  Release  of  Encryption  Key  Components  in  Conjunction  with  Intercepts  Pursuant  to  FISA,  ”  Feb.  4,  1994. 

*  Federal  Register  (Feb.  9,  1994),  op.  cit.  footnote  1,  pp.  5998-6002. 

*E.  Brickell  (Sandia  National  Laboratories)  et  al.,  “SKIPJACK  Review  Interim  Report-The  SKIPJACK  Algorithm,  ”  July  28, 1993. 
See  also  “Fact  Sheet— NIST  Cryptography  Activities,”  Feb.  4,  1994 


(continued) 
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BOX  2-3  (cont’d.):  The  Escrowed  Encryption  Standard 


Based  on  its  review  of  the  public  comments,  NIST  recommended  that  the  Secretary  of  Commerce  issue 
the  EES  as  a  federal  information  processing  standard.’°NIST  noted  that  almost  all  of  the  comments  re¬ 
ceived  during  the  review  period  were  negative,  but  concluded  that,  “many  of  these  comments  reflected 
misunderstanding  or  skepticism  that  the  EES  would  be  a  voluntary  standard."  "The  Clinton  Administration 
also  carried  out  a  10-month  encryption  policy  review  that  presumably  played  a  role  in  choosing  to  issue  the 
EES  as  a  FIPS,  but  the  substance  of  that  review  has  not  been  made  public  and  was  not  available  to  OTA. 
Additionally,  the  Clinton  Administration  created  an  interagency  working  group  on  encryption  and  telecom¬ 
munications  that  includes  representatives  of  agencies  that  participated  in  the  policy  review.  The  interagen¬ 
cy  group  was  to  “work  with  industry  on  technologies  like  the  Key  Escrow  chip  [i.  e.,  EES],  to  evaluate  pos¬ 
sible  alternatives  to  the  chip,  and  to  review  Administration  policies  regarding  encryption  as  developments 
warrant.  ”'2 

In  early  1995,  an  alternative,  commercial  key-escrow  encryption  system  being  developed  by  Trusted 
Information  Systems,  Inc.  (TIS)  was  undergoing  internal  government  review  to  determine  whether  such  an 
approach  could  meet  national  security  and  law  enforcement  objectives.  The  TIS  key-escrow  system  does 
software-based  escrowing  and  encryption  using  the  “triple-DES”  version  of  the  Data  Encryption  Stan- 
dard."3The  initial  version  of  the  system  is  designed  for  use  in  encrypting  files  or  email,  but  the  TIS  ap¬ 
proach  could  also  be  used  for  real-time  telecommunications. 

In  January  1995,  AT&T  Corp.  and  VLSI  Technology,  Inc.,  announced  plans  to  develop  chips  implement¬ 
ing  the  RSA  algorithm  and  “triple  DES”  for  encryption.  The  chips  would  be  used  in  a  personal  computers, 
digital  telephones,  and  video  decoder  boxes.” 


‘“Ibid.,  and  Federal  Register  (  Feb.  9, 1994),  OP.  Cit.,  footnote  1. 

“Ibid. 

12  White  House  press  release  and  enclosures,  Feb.  4, 1994,  “Working  Group  on  Encryption  and  Telecommunications.  ” 

13 Stephen  T.  Walker  et  al.,  "Commercial  Key  Escrow:  Something  for  Everyone  Nowand  For  the  Future,  ”  TIS  Report  No.  541, 
Trusted  Information  Systems,  Inc.,  Jan.  3,  1995. 

“Jared  Sandberg  and  Don  Clark,  “AT&T,  VLSI  Technology  To  Develop  Microchips  That  Offer  Data  Security, The  Wall  Street  Jour¬ 
nal,  Jan.  31, 1995. 

SOURCE:  Off  Ice  of  Technology  Assessment,  1995;  drawing  from  OTA,  Information  Security  And  Privacy  in  Networked  Environments 
(OTA-TCT-606,  September  1994),  pp.  118-119  and  sources  cited  therein  and  below. 


eliciting  and  aggregating  bulk  orders  for  FOR- 
TEZZA  in  order  to  support  the  award  of  a  large- 
scale  production  contract  in  the  fall,  ideally  for 
200,000  to  400,000  units  in  order  to  achieve  the 
target  unit  price  of  $100.” 

The  algorithm  specified  in  the  EES  has  not  been 
published.  The  secret  encryption  key  length  for 


Skipjack  is  80  bits;  a  key-escrowing  scheme  is 
built  into  ensure  “lawfully  authorized”  electronic 
surveillance. 24 The  algorithm  is  classified  and  is 
intended  to  be  implemented  only  in  tamper-resis¬ 
tant,  hardware  modules.25  This  approach  makes 
the  confidentiality  function  of  the  Skipjack  en- 


*3  Ibid.  According  to  the  NSA,  unit  prices  for  FORTEZZA  cards  in  small  quantities  are  on  the  order  of  $150,  of  which  about  $98  is  for  the 
Capstone  chip.  The  Capstone  chip  implements  the  Skipjack  algorithm,  plus  key-exchange  and  digital-signature  (DSS)  functions. 
v  Federal  Register,  ibid.,  p.  6003. 

15 Federal  Register,  ibid.,  pp.  5997-6005. 
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cryption  algorithm  available  in  a  controlled  fash¬ 
ion,  without  disclosing  the  algorithm’s  design 
principles  or  thereby  increasing  users’  abilities  to 
employ  cryptographic  principles.  One  of  the  rea¬ 
sons  stated  for  specifying  a  classified,  rather  than 
published,  encryption  algorithm  in  the  EES  is  to 
prevent  independent  implementation  of  Skipjack 
without  the  law  enforcement  access  features. 

The  federal  Data  Encryption  Standard  was  first 
approved  in  1976  and  was  most  recently  reaf¬ 
firmed  in  1993.  The  DES  specifies  an  algorithm 
that  can  be  used  to  protect  unclassified  informa¬ 
tion,  as  needed,  while  it  is  being  communicated  or 
stored.26  The  DES  algorithm  has  been  made  pub¬ 
lic  (i.e.,  it  has  been  published).  When  the  DES  is 
used,  users  can  generate  their  own  encryption 
keys;  the  secret  encryption  key  for  DES  is  56  bits 
long.  The  DES  does  not  require  the  keys  to  be  “es¬ 
crowed”  or  deposited  with  any  third  party. 

The  1993  reaffirmation  of  the  DES — now  in 
software,  as  well  as  hardware  and  firmware  imple¬ 
mentations — may  be  the  last  time  it  is  reaffirmed 
as  a  federal  standard.  FIPS  Publication  46-2 
(“Data  Encryption  Standard”)  noted  that  the  algo¬ 
rithm  will  be  reviewed  within  five  years  to  assess 
its  adequacy  against  potential  new  threats,  includ¬ 
ing  advances  in  computing  and  cryptanalysis: 

At  its  next  review  (1998)  [the  DES  algorithm] 
will  be  over  twenty  years  old.  NIST  [National  Insti¬ 
tute  of  Standards  and  Technology]  will  consider  al¬ 
ternatives  which  offer  a  higher  level  of  security. 
One  of  these  alternatives  may  be  proposed  as  a  re¬ 
placement  standard  at  the  1998  review.27 


Given  that  the  Skipjack  algorithm  was  selected  as 
a  standard  (the  EES)  for  telephony,  it  is  possible 
that  an  implementation  of  Skipjack  (or  some  other 
form  of  key-escrow  encryption)  will  be  selected  as 
a  FIPS  to  replace  the  DES  for  computer  commu¬ 
nications  and/or  file  encryption. 

An  alternative  successor  to  the  DES  that  is  fa¬ 
vored  by  nongovernmental  users  and  experts  is  a 
variant  of  DES  called  triple-encryption  DES.  In 
“triple  DES,”  the  algorithm  is  used  sequentially 
with  three  different  keys,  to  encrypt,  decrypt,  then 
re-encrypt.  Triple  encryption  with  the  DES  offers 
more  security  than  having  a  112-bit  DES  key. 
Therefore,  nongovernmental  experts  consider  that 
triple  DES  “appears  inviolate  against  all  adver¬ 
saries  for  the  foreseeable  future.”28  There  is,  how¬ 
ever,  no  FIPS  for  triple-encryption  DES. 

Unlike  the  EES  algorithm,  the  algorithm  in  the 
federal  Digital  Signature  Standard  has  been  pub¬ 
lished.29  The  public-key  algorithm  specified  in 
the  DSS  uses  a  private  key  in  signature  generation, 
and  a  corresponding  public  key  for  signature  veri¬ 
fication  (see  box  2-2).  However,  the  DSS  tech¬ 
nique  was  chosen  so  that  public-key  encryption 
functions  would  not  be  available  to  users.30  This 
is  significant  because  public-key  encryption  is  ex¬ 
tremely  useful  for  key  management  and  could, 
therefore,  contribute  to  the  spread  and  use  of  non- 
escrowed  encryption.31  At  present,  there  is  no 
FIPS  for  key  exchange. 

While  other  means  of  exchanging  electronic 
keys  are  possible,32  none  is  so  mature  as  public- 


26  NIST,  “Data  Encryption  Standard  (DES),”  FIPS  PUB  46-2  (Gaithersburg,  MD:  U.S.  Department  of  Commerce,  Dec.  30,  1993). 

27  Ibid.,  p.  6. 

28  Martin  Heilman,  Professor  of  Electrical  Engineering,  Stanford  University,  personal  communication,  May  24,  1994;  also  see  box  4-3  of 
the  1994  report. 

29  See  appendix  C  of  OTA,  op.  cit.,  footnote  4,  for  a  history  of  the  DSS. 

30  According  to  F.  Lynn  McNulty,  NIST  Associate  Director  for  Computer  Security,  the  rationale  for  adopting  the  technique  used  in  the  DSS 
was  that,  “We  wanted  a  technology  that  did  signatures— and  nothing  else— very  well.”  (Response  to  a  question  from  Chairman  Rick  Boucher  in 
testimony  before  the  Subcommittee  on  Science  of  the  House  Committee  on  Science,  Space,  and  Technology,  Mar.  22, 1994.) 

31  Public-key  encryption  can  be  used  for  confidentiality  and,  thereby,  for  secure  key  exchange.  Thus,  public-key  encryption  can  facilitate 
the  use  of  symmetric  encryption  methods  like  the  DES  or  triple  DES.  See  figure  2-3. 

32  See,  e.g.,  Tom  Leighton  (Department  of  Mathematics,  Massachusetts  Institute  of  Technology),  and  Silvio  Micali  (MIT  Laboratory  for 
Computer  Science),  “Secret-Key  Agreement  Without  Public-Key  Cryptography  (extended  abstract),”  obtained  from  S.  Micali,  1993. 
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FIGURE  2-4:  Secret-Key  Distribution  Using  Public-Key  Cryptography 
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SOURCE:  Office  of  Technology  Assessment,  1994. 


key  technology.  In  contrast  to  the  technique  cho¬ 
sen  for  the  DSS,  the  technique  used  in  the  most 
widely  used  commercial  digital  signature  system 
(based  on  the  Rivest-Shamir-Adleman,  or  RSA, 
algorithm)  can  also  encrypt.  Therefore,  the  RSA 
techniques  can  be  used  for  secure  key  exchange 
(i.e.,  exchange  of  “secret”keys,  such  as  those  used 
with  the  DES),  as  well  as  for  signatures  (see  figure 


2-4).  Another  public-key  technique,  called  the 
Diffie-Hellman  method,  can  also  be  used  to  gener¬ 
ate  encryption  keys  (see  figure  2-5),  but  does  not 
encrypt.” 

The  1994  OTA  report  concluded  that  both  the 
EES  and  the  DSS  are  federal  standards  that  are 
part  of  a  long-term  control  strategy  intended  to  re- 


"The  public-key  concept  was  first  published  by  Whitfield  Diffie  and  Martin  Heilman  in  “New  Directions  in  Cryptography/' IEEE  Transac¬ 
tions  on  Information  Theory ,  vol.  IT-22,  No.  6,  November  1976,  pp.  644-654.  Diffie  and  Heilman  described  how  such  a  system  could  be  used  for 
key  distribution  and  to  “sign”  individual  messages. 


Chapter  2  Overview  of  the  1994  OTA  Report  on  Information  Security  and  Privacy  59 


Alice  and  Bob  have  calculated 
the  same  session  key 


1 


i  i 


Alice  encrypts  and  decrypts 

R 1;  Bob  encrypts  and  decrypts 

communication  with  Bob 

—  ■  communication  with  Alice 

using  their  shared  session  key 

\H::  using  their  shared  session  key 

NOTE:  An  authentication  scheme  for  the  public  keys  may  also  be  used 
SOURCE:  Office  of  Technology  Assessment,  1994. 


tard  the  general  availability  of  “unbreakable”  or 
“hard  to  break”  encryption  within  the  United 
States,  for  reasons  of  national  security  and  law  en¬ 
forcement.  34  OTA  viewed  the  EES  and  DSS  as 
complements  in  this  overall  control  strategy,  in¬ 
tended  to  discourage  future  development  and  use 
of  encryption  without  built-in  law  enforcement 
access,  in  favor  of  key-escrowed  and  related  en¬ 
cryption  technologies.  If  the  EES  and/or  other 


key-escrow  encryption  standards  (e.g.,  for  use  in 
computer  networks)  become  widely  used-or  en¬ 
joy  a  large,  guaranteed  government  market — this 
could  ultimately  reduce  the  variety  of  alternative 
cryptography  products  through  market  domi¬ 
nance  that  makes  alternatives  more  scarce  or  more 
costly. 


'See  OTA,  op.cit.,  footnote  4,  ch.  4. 
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Federal  Standards  and  the 
Computer  Security  Act  of  1987 

The  Computer  Security  Act  of  1987  (Public  Law 
100-235)  is  fundamental  to  development  of  feder¬ 
al  standards  for  safeguarding  unclassified  in¬ 
formation,  to  balancing  national  security  and 
other  objectives  in  implementing  security  and  pri¬ 
vacy  policies  within  the  federal  government,  and 
to  other  issues  concerning  government  control  of 
cryptography.  Implementation  of  the  Computer 
Security  Act  has  been  controversial,  especially  re¬ 
garding  the  respective  roles  of  NIST  and  NSA  in 
standards  development  and  the  chronic  shortage 
of  resources  for  NIST’s  computer  security  pro¬ 
gram  to  fulfill  its  responsibilities  under  the  act 
(see  detailed  discussion  in  chapter  4  of  the  1994 
OTA  report).35 

The  Computer  Security  Act  of  1987  was  a  legis¬ 
lative  response  to  overlapping  responsibilities  for 
computer  security  among  several  federal  agen¬ 
cies,  heightened  awareness  of  computer  security 
issues,  and  concern  over  how  best  to  control  in¬ 
formation  in  computerized  or  networked  form. 
The  act  established  a  federal  government  comput¬ 
er-security  program  that  would  protect  all  un¬ 
classified,  sensitive  information  in  federal 
government  computer  systems  and  would  devel¬ 
op  standards  and  guidelines  to  facilitate  such 
protection. 

Specifically,  the  Computer  Security  Act  as¬ 
signed  responsibility  for  developing  government- 
wide,  computer-system  security  standards  (e.g., 
the  FIPS)  and  guidelines  and  security-training 
programs  to  the  National  Bureau  of  Standards 
(NBS).  NBS  is  now  the  National  Institute  of  Stan¬ 
dards  and  Technology,  or  NIST.  According  to  its 
responsibilities  under  the  act,  NIST  recommends 
federal  information  processing  standards  and 


guidelines  to  the  Secretary  of  Commerce  for  ap¬ 
proval  (and  promulgation,  if  approved).  These 
FIPS  do  not  apply  to  classified  or  “Warner 
Amendment”  systems.36  NIST  can  draw  on  the 
technical  expertise  of  the  National  Security 
Agency  in  carrying  out  its  responsibilities,  but  the 
NSA’s  role  according  to  Public  Law  100-235  is  an 
advisory,  rather  than  leadership,  one. 

Section  21  of  the  Computer  Security  Act  estab¬ 
lished  a  Computer  System  Security  and  Privacy 
Advisory  Board.  The  board,  appointed  by  the  Sec¬ 
retary  of  Commerce,  is  charged  with  identifying 
emerging  safeguard  issues  relative  to  computer 
systems  security  and  privacy,  advising  the  NBS 
(NIST)  and  Secretary  of  Commerce  on  security 
and  privacy  issues  pertaining  to  federal  computer 
systems,  and  reporting  its  findings  to  the  Secre¬ 
tary  of  Commerce,  the  Director  of  OMB,  the  Di¬ 
rector  of  NSA,  and  Congress.  Additionally,  the  act 
required  federal  agencies  to  identify  computer 
systems  containing  sensitive  information,  to  de¬ 
velop  security  plans  for  identified  systems,  and  to 
provide  periodic  training  in  computer  security  for 
all  federal  employees  and  contractors  who  man¬ 
age,  use,  or  operate  federal  computer  systems.  Ap¬ 
pendix  B,  drawn  from  the  1994  OTA  report, 
provides  more  background  on  the  purpose  and  im¬ 
plementation  of  the  Computer  Security  Act  and  on 
the  FIPS. 

Federal  Standards  and  the  Marketplace 

As  the  1994  OTA  report  noted,  not  all  government 
attempts  at  influencing  the  marketplace  through 
the  FIPS  and  procurement  polices  are  successful. 
For  example,  the  government  made  an  early  com¬ 
mitment  to  the  Open  Systems  Interconnection 
(OSI)  protocols  for  networking,  but  it  is  the  ubiq¬ 
uitous  Transmission  Control  Protocol/Internet 


35  Ibid.,  chapter  4  and  appendix  B.  NIST’s  FY  1995  computer-security  budget  was  on  the  order  of  $6.5  million,  with  $4.5  million  of  this 
coming  from  appropriated  funds  for  “core”  activities  and  the  remainder  from  “reimbursable”  funds  from  other  agencies,  mainly  the  Defense 
Department. 

36  Tha  Warner  Amendment  (Public  Law  97-86)  excluded  certain  types  of  military  and  intelligence  “automatic  data  processing  equipment” 
procurements  from  the  requirements  of  section  111  of  the  Federal  Property  and  Administrative  Services  Act  of  1949  (40  U.S.C.  795).  Public 
Law  100-235  pertains  to  federal  computer  systems  that  come  under  section  111  of  the  Federal  Property  and  Administrative  Services  Act  of 
1949. 
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Protocol  (TCP/IP)  that  has  enjoyed  wide  use 
throughout  the  world  in  the  Internet  and  other  net¬ 
works.  However,  the  FIPS  usually  influence  the 
technologies  used  by  federal  agencies  and  provide 
a  basis  for  interoperability,  thus  creating  a  large 
and  stable,  “target  market”  for  safeguard  vendors. 
If  the  attributes  of  the  standard  technology  are  also 
applicable  to  the  private  sector  and  the  standard 
has  wide  appeal,  an  even  larger  but  still  relatively 
stable  market  should  result.  The  technological  sta¬ 
bility  means  that  firms  compete  less  in  terms  of 
the  attributes  of  the  fundamental  technology  and 
more  in  terms  of  cost,  ease  of  use,  and  so  forth. 
Therefore,  firms  need  to  invest  less  in  research  and 
development  (especially  risky  for  a  complex 
technology  like  cryptography)  and  in  convincing 
potential  customers  of  product  quality.  This  can 
result  in  higher  profits  for  producers,  even  in  the 
long  run,  and  in  increased  availability  and  use  of 
safeguards  based  on  the  standard. 

In  the  1970s,  promulgation  of  the  DES  as  a 
stable  and  certified  technology — at  a  time  when 
the  commercial  market  for  cryptography-based 
safeguards  for  unclassified  information  was 
emerging — stimulated  supply  and  demand.  Al¬ 
though  the  choice  of  the  algorithm  was  originally 
controversial  due  to  concerns  over  NS  A’ s  involve¬ 
ment,  the  DES  gained  wide  acceptance  and  has 
been  the  basis  for  several  industry  standards,  in 
large  part  because  it  was  a  published  standard  that 
could  be  freely  evaluated  and  implemented.  Al¬ 
though  DES  products  are  subject  to  U.S.  export 
controls,  DES  technology  is  also  widely  available 
around  the  world  and  the  algorithm  has  been 
adopted  in  several  international  standards.  The 
process  by  which  the  DES  was  developed  and 
evaluated  also  stimulated  private  sector  interest  in 
cryptographic  research,  ultimately  increasing  the 
variety  of  commercial  safeguard  technologies. 

The  1994  OTA  report  regarded  the  introduction 
of  an  incompatible  new  federal  standard — for  ex¬ 
ample,  the  Escrowed  Encryption  Standard — as 


destabilizing.  At  present,  the  EES  and  related 
technologies  have  gained  little  favor  in  the  private 
sector — features  such  as  the  government  key-es¬ 
crow  agencies,  classified  algorithm,  and  hard¬ 
ware-only  implementation  all  contribute  to  its 
lack  of  appeal.  But,  if  the  EES  and  related  technol¬ 
ogies  (e.g.,  for  data  communications)  ultimately 
do  manage  to  gain  wide  appeal  in  the  marketplace, 
they  might  be  able  to  “crowd  out”  safeguards  that 
are  based  upon  other  cryptographic  techniques 
and/or  do  not  support  key  escrowing.37 

The  1 994  OTA  report  noted  that  this  type  of  mar¬ 
ket  distortion,  intended  to  stem  the  supply  of  alter¬ 
native  products,  may  be  a  long-term  objective  of 
the  key-escrow  encryption  initiative.  In  the  long 
term,  a  loss  of  technological  variety  is  significant 
to  private  sector  cryptography,  because'more  di¬ 
verse  research  and  development  efforts  tend  to  in¬ 
crease  the  overall  pace  of  technological  advance. 
In  the  near  term,  technological  uncertainty  may 
delay  widespread  investments  in  any  new  safe¬ 
guard,  as  users  wait  to  see  which  technology  pre¬ 
vails.  The  costs  of  additional  uncertainties  and 
delays  due  to  control  interventions  are  ultimately 
borne  by  the  private  sector  and  the  public. 

Other  government  policies  can  also  raise  costs, 
delay  adoption,  or  reduce  variety.  For  example, 
export  controls  have  the  effect  of  segmenting  do¬ 
mestic  and  export  encryption  markets.  This 
creates  additional  disincentives  to  invest  in  the  de¬ 
velopment — or  use — of  robust,  but  nonexport¬ 
able,  products  with  integrated  strong  encryption 
(see  discussion  below). 

Export  Controls 

Another  locus  of  concern  is  export  controls  on 
cryptography  (see  appendix  C).38  The  United 
States  has  two  regulatory  regimes  for  exports,  de¬ 
pending  on  whether  the  item  to  be  exported  is  mil¬ 
itary  in  nature,  or  is  “dual-use,”  having  both 
civilian  and  military  uses.  These  regimes  are  ad- 


37  Ibid.,  pp.  128-132.  A  large,  stable,  lucrative  federal  market  could  divert  vendors  from  producing  alternative,  riskier  products;  product 
availability  could  draw  private  sector  customers. 

38  For  more  detail,  see  ibid.,  chapters  1  and  4. 
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ministered  by  the  State  Department  and  the  Com¬ 
merce  Department,  respectively.  Both  regimes 
provide  export  controls  on  selected  goods  or 
technologies  for  reasons  of  national  security  or 
foreign  policy.  Licenses  are  required  to  export 
products,  services,  or  scientific  and  technical  data 
originating  in  the  United  States,  or  to  re-export 
these  from  another  country.  Licensing  require¬ 
ments  vary  according  to  the  nature  of  the  item  to 
be  exported,  the  end  use,  the  end  user,  and,  in  some 
cases,  the  intended  destination.  For  many  items 
under  Commerce  jurisdiction,  no  specific  approv¬ 
al  is  required  and  a  “general  license”  applies  (e.g., 
when  the  item  in  question  is  not  military  or  dual- 
use  and/or  is  widely  available  from  foreign 
sources).  In  other  cases,  an  export  license  must  be 
applied  for  from  either  the  State  Department  or  the 
Commerce  Department,  depending  on  the  nature 
of  the  item.  In  general,  the  State  Department’s  li¬ 
censing  requirements  are  more  stringent  and 
broader  in  scope.39 

Software  and  hardware  for  robust,  user-con¬ 
trolled  encryption  are  under  State  Department 
control,  unless  State  grants  jurisdiction  to  Com¬ 


merce.  This  has  become  increasingly  controver¬ 
sial,  especially  for  the  information  technology  and 
software  industries.40  The  impact  of  export  con¬ 
trols  on  the  overall  cost  and  availability  of  safe¬ 
guards  is  especially  troublesome  to  business  and 
industry  at  a  time  when  U.S.  high-technology 
firms  find  themselves  as  targets  for  sophisticated 
foreign-intelligence  attacks  and  thus  have  urgent 
need  for  sophisticated  safeguards  that  can  be  used 
in  operations  worldwide,  as  well  as  for  secure 
communications  with  overseas  business  partners, 
suppliers,  and  customers.41  Software  producers 
assert  that,  although  other  countries  do  have  ex¬ 
port  and/or  import  controls  on  cryptography,  sev¬ 
eral  countries  have  more  relaxed  export  controls 
on  cryptography  than  does  the  United  States.42 

On  the  other  hand,  U.S.  export  controls  may 
have  substantially  slowed  the  proliferation  of 
cryptography  to  foreign  adversaries  over  the 
years.  Unfortunately,  there  is  little  public  explana¬ 
tion  on  the  degree  of  success  of  these  export  con¬ 
trols43  and  the  necessity  for  maintaining  strict 
controls  on  strong  encryption44  in  the  face  of  for- 


39  Ibid.,  pp.  150-154. 

40  To  ease  some  of  these  burdens,  the  State  Department  announced  new  licensing  procedures  on  Feb.  4, 1994.  These  changes  were  expected 
to  include  license  reform  measures  for  expedited  distribution  (to  reduce  the  need  to  obtain  individual  licenses  for  each  end  user),  rapid  review  of 
export  license  applications,  personal-use  exemptions  for  U.S.  citizens  temporarily  taking  encryption  products  abroad  for  their  own  use,  and 
special  licensing  arrangements  allowing  export  of  key-escrow  encryption  products  (e.g.,  EES  products)  to  most  end  users.  At  this  writing,  expe- 
dited-distribution  reforms  were  in  place  (Federal  Register  pt.  2, 1994,  pp.  45621-45623),  but  personal-use  exemptions  were  still  under  con¬ 
tention  (Karen  Hopkinson,  Office  of  Defense  Trade  Controls,  personal  communication,  Mar.  8,  1995). 

41  See,  e.g.,  U.S.  Congress,  House  of  Representatives,  Subcommittee  on  Economic  and  Commercial  Law,  Committee  on  the  Judiciary,  The 
Threat  of  Foreign  Economic  Espionage  to  U.S.  Corporations ,  hearings,  102d  Congress,  2d  sess.,  Apr.  29  and  May  7, 1992,  Serial  No.  65  (Wash¬ 
ington,  DC:  U.S.  Government  Printing  Office,  1992).  See  also  discussion  of  business  needs  and  export  controls  in  chapter  3  of  this  background 
paper. 

42  OTA,  op.  cit.,  footnote  4,  pp.  154-160.  Some  other  countries  do  have  stringent  export  and/or  import  restrictions. 

43  For  example,  the  Software  Publishers  Association  (SPA)  has  studied  the  worldwide  availability  of  encryption  products  and,  as  of  October 
1994,  found  170  software  products  (72  foreign,  98  U.S.-made)  and  237  hardware  products  (85  foreign,  1 52  U.S. -made)  implementing  the  DES 
algorithm  for  encryption.  (Trusted  Information  Systems,  Inc.  and  Software  Publishers  Association,  Encryption  Products  Database  Statistics , 
October  1994.)  Also  see  OTA,  op.  cit.,  footnote  4,  pp.  156-160. 

44  For  a  discussion  of  export  controls  and  network  dissemination  of  encryption  technology,  see  Simson  Garfinkle,  PGP:  Pretty  Good  Priva¬ 
cy  (Sebastopol,  CA;  O’Reilly  and  Assoc.,  1995).  PGP  is  a  public-key  encryption  program  developed  by  Phil  Zimmerman.  Variants  of  the  PGP 
software  (some  of  which  infringe  the  RS  A  patent  in  the  United  States)  have  spread  worldwide  over  the  Internet.  Zimmerman  has  been  under 
grand  jury  investigation  since  1993  for  allegedly  breaking  the  munitions  export-control  laws  by  permitting  the  software  to  be  placed  on  an 
Internet-accessible  bulletin  board  in  the  United  States  in  1 991 .  (See  Vic  Sussman,  “Lost  in  Kafka  Territory,”  U.  S.  News  and  World  Report ,  Apr. 
3,  1995,  pp.  30-31.) 
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eign  supply  and  networks  like  the  Internet  that 
seamlessly  cross  national  boundaries. 

Appendix  C  drawn  from  the  1994  OTA  report, 
provides  more  background  on  export  controls  on 
cryptography.  In  September  1994,  after  the  OTA 
report  had  gone  to  press,  the  State  Department  an¬ 
nounced  an  amendment  to  the  regulations  imple¬ 
menting  section  38  of  the  Arms  Export  Control 
Act.45  The  new  rule  implements  one  of  the  re¬ 
forms  applicable  to  encryption  products  that  were 
announced  on  February  4,  1994  by  the  State  De¬ 
partment  (see  footnote  47  below  and  also  chapter 
4  of  the  1994  OTA  report).  It  established  a  new  li¬ 
censing  procedure  to  permit  U.S.  encryption 
manufacturers  to  make  multiple  shipments  of 
some  encryption  items  covered  by  Category 
XIII(b)(l)  of  the  Munitions  List  (see  appendix  C) 
directly  to  end  users  in  approved  countries,  with¬ 
out  obtaining  individual  licenses.45  Other  an¬ 
nounced  reforms,  still  to  be  implemented,  include 
special  licensing  procedures  allowing  export  of 
key-escrow  encryption  products  to  “most  end  us¬ 
ers.”47  The  ability  to  export  strong,  key-escrow 
encryption  products  would  presumably  increase 
the  appeal  of  escrowed-encryption  products  to  pri¬ 
vate  sector  safeguard  developers  and  users. 

In  the  103d  Congress,  legislation  intended  to 
streamline  export  controls  and  ease  restrictions  on 
mass-market  computer  software,  hardware,  and 
technology,  including  certain  encryption  soft¬ 
ware,  was  introduced  by  Representative  Maria 
Cantwell  (H.R.  3627)  and  Senator  Patty  Murray 
(S.  1 846).  In  considering  the  Omnibus  Export  Ad¬ 
ministration  Act  of  1994  (H.R.  3937),  the  House 


Committee  on  Foreign  Affairs  reported  a  version 
of  the  bill  in  which  most  computer  software  (in¬ 
cluding  software  with  encryption  capabilities) 
was  under  Commerce  Department  controls  and  in 
which  export  restrictions  for  mass-market  soft¬ 
ware  with  encryption  were  eased.  In  its  report,  the 
House  Permanent  Select  Committee  on  Intelli¬ 
gence  struck  out  this  portion  of  the  bill  and  re¬ 
placed  it  with  a  new  section  calling  for  the 
President  to  report  to  Congress  within  150  days  of 
enactment,  regarding  the  current  and  future  in¬ 
ternational  market  for  software  with  encryption 
and  the  economic  impact  of  U.S.  export  controls 
on  the  U.S.  computer  software  industry.48 

At  the  end  of  the  103d  Congress,  the  omnibus 
export  administration  legislation  had  not  been  en¬ 
acted.  Both  the  House  and  Senate  bills  contained 
language  calling  for  the  Clinton  Administration  to 
conduct  comprehensive  studies  on  the  interna¬ 
tional  market  and  availability  of  encryption 
technologies  and  the  economic  effects  of  U.S.  ex¬ 
port  controls.  In  a  July  20,  1994,  letter  to  Repre¬ 
sentative  Cantwell,  Vice  President  Gore  had 
assured  her  that  the  “best  available  resources  of 
the  federal  government”  would  be  used  in  con¬ 
ducting  these  studies  and  that  the  Clinton  Admin¬ 
istration  would  “reassess  our  existing  export 
controls  based  on  the  results  of  these  studies.”49 

At  this  writing,  the  Commerce  Department  and 
NSA  are  assessing  the  economic  impact  of  U.S. 
export  controls  on  cryptography  on  the  U.S.  com¬ 
puter  software  industry.50  As  part  of  the  study, 
NSA  is  determining  the  foreign  availability  of  en- 


45  Department  of  State,  Bureau  of  Political-Military  Affairs,  22  CFR  parts  1 23  and  1 24,  Federal  Register ,  vol.  59,  No.  1 70,  Sept.  2, 1 994,  pp. 
45621-45623. 

46  Category  XIII(b)(l )  covers  “Information  Security  Systems  and  equipment,  cryptographic  devices,  software  and  components  specifically 
designed  or  modified  therefore,”  in  particular,  “cryptographic  and  key-management  systems  and  associated  equipment,  subcomponents,  and 
software  capable  of  maintaining  information  or  information-system  secrecy/confidentiality.” 

47  Martha  Harris,  Deputy  Assistant  Secretary  for  Political-Military  Affairs,  U.S.  Department  of  State,  “Encryption— Export  Control  Re¬ 
form,”  statement,  Feb.  4,  1994.  See  OTA,  op.  cit.,  footnote  4,  pp.  159-160. 

48  A  study  of  this  type  (see  below)  is  expected  to  be  completed  in  mid-1995. 

49  Vice  President  A1  Gore,  letter  to  Representative  Maria  Cantwell,  July  20,  1994.  See  OTA,  op.  cit.,  footnote  4,  pp.  11-13. 

50  Maurice  Cook,  Bureau  of  Export  Administration,  Department  of  Commerce,  personal  communication,  Mar.  7,  1995. 
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cryption  products.  The  study  is  scheduled  to  be 
delivered  to  the  National  Security  Council  (NSC) 
by  July  1 , 1 995 .  According  to  the  Council,  it  is  an¬ 
ticipated  that  there  will  be  both  classified  and  un¬ 
classified  sections  of  the  study;  there  may  be  some 
public  release  of  the  unclassified  material.51  In 
addition,  an  ongoing  National  Research  Council 
study  that  would  support  a  broad  congressional  re¬ 
view  of  cryptography  (and  that  is  expected  to  ad¬ 
dress  export  controls)  is  due  to  be  completed  in 
1996.52  At  this  writing,  the  NRC  study  committee 
is  gathering  public  input  on  cryptography  issues. 

In  the  104th  Congress,  Representative  Toby 
Roth  has  introduced  the  “Export  Administration 
Act  of  1995”  (H.R.  361).  This  bill  does  not  in¬ 
clude  any  specific  references  to  cryptography;  at 
this  writing,  it  is  not  clear  whether  or  when  the 
contentious  issue  of  cryptography  export  controls 
will  become  part  of  legislative  deliberations.  Al¬ 
ternatively,  the  Clinton  Administration  could  ease 
export  controls  on  cryptography  without  legisla¬ 
tion.  As  was  noted  above,  being  able  to  export 
key-escrow  encryption  products  would  presum¬ 
ably  make  escrowed-encryption  products  more  at¬ 
tractive  to  commercial  developers  and  users. 
Therefore,  the  Clinton  Administration  could  ease 
export  requirements  for  products  with  integrated 
key  escrowing  as  an  incentive  for  the  commercial 
development  and  adoption  of  such  products  (see 
discussion  of  cryptography  initiatives  in  chapter 
4). 

I  Overview  of  Issues  and  Options 

As  noted  above,  the  1994  OTA  report  Information 
Security  and  Privacy  in  Network  Environments 
focuses  on  three  sets  of  policy  issues: 

1.  national  cryptography  policy,  including  federal 
information  processing  standards  and  export 
controls; 

2.  guidance  on  safeguarding  unclassified  in¬ 
formation  in  federal  agencies;  and 


3.  legal  issues  and  information  security,  including 
electronic  commerce,  privacy,  and  intellectual 
property. 

Appendix  E  of  this  paper,  based  on  chapter  1  of 
the  1994  report,  reviews  the  set  of  policy  options, 
about  two  dozen,  developed  by  OTA.  The  need  for 
openness,  oversight,  and  public  accountability — 
given  the  broad  public  and  business  impacts  of 
these  policies — runs  throughout  the  discussion  of 
possible  congressional  actions. 

Two  key  questions  underlying  consideration  of 
many  of  these  options — in  particular,  those  ad¬ 
dressing  cryptography  policy  and  unclassified  in¬ 
formation  security  within  the  federal  government 
are: 

1.  How  will  we  as  a  nation  develop  and  main¬ 
tain  the  balance  among  traditional  “na¬ 
tional  security”  (and  law  enforcement) 
objectives  and  other  aspects  of  the  public  in¬ 
terest,  such  as  economic  vitality,  civil  liber¬ 
ties,  and  open  government? 

2.  What  are  the  costs  of  government  efforts  to 
control  cryptography  and  who  will  bear 
them? 

Some  of  these  costs — for  example,  the  incremen¬ 
tal  cost  of  requiring  a  “standard”  solution  that  is 
less  cost-effective  than  the  “market”  alternative  in 
meeting  applicable  security  requirements — may 
be  relatively  easy  to  quantify,  compared  with  oth¬ 
ers.  But  none  of  these  cost  estimates  will  be  easy 
to  make.  Some  costs  may  be  extremely  difficult  to 
quantify,  or  even  to  bound — for  example,  the  im¬ 
pact  of  technological  uncertainties,  delays,  and 
regulatory  requirements  on  U.S.  firms’  abilities  to 
compete  effectively  in  the  international  market¬ 
place  for  information  technologies.  Uldmately, 
however,  these  costs  are  all  borne  by  the  public, 
whether  in  the  form  of  taxes,  product  prices,  or 
foregone  economic  opportunities  and  earnings. 


51  Bill  Clements,  National  Security  Council,  personal  communication,  Mar.  21,  1995. 

52  For  information  about  the  NRC  study,  which  was  mandated  by  Public  Law  103-160,  contact  Herb  Lin,  National  Research  Council,  2101 
Constitution  Avenue,  N.W.,  Washington,  DC,  20418  (crypto@nas.edu).  See  discussion  in  chapter  1  and  4  of  OTA,  op.  cit.,  footnote  4. 


Digest  of 
OTA  Workshop 
Discussion 


At  the  request  of  the  Senate  Committee  on  Governmental 
Affairs,  the  Office  of  Technology  Assessment  (OTA)  held 
a  workshop  titled  “Information  Security  and  Privacy  in 
Network  Environments:  What  Next?”  on  December  6, 
1994,  as  part  of  its  follow-on  activities  after  the  release  of  the  re¬ 
port  Information  Security  and  Privacy  in  Network  Environ¬ 
ments }  The  purpose  of  the  workshop  was  to  hear  the  reactions 
from  the  business  and  network-user  communities  to  the  issues 
OTA  had  identified,  as  well  as  their  priorities  for  any  government 
actions.  This  chapter  will  review  the  workshop  discussion  and 
identify  major  themes  that  emerged,  particularly  regarding  export 
controls  and  the  business  environment,  federal  cryptography 
policy,  and  characteristics  of  information-security  “best  prac¬ 
tices”  that  are  germane  to  consideration  of  government  informa¬ 
tion  security. 

OVERVIEW 

Workshop  participants  came  from  the  business,  legal,  university, 
and  public-interest  communities.  Individuals’  areas  of  experi¬ 
ence  and  expertise  included  computer,  telecommunication,  and 
security  technologies;  information-security  education  and  prac¬ 
tice  in  the  private  and  public  sectors;  management;  and  law. 
About  half  of  the  20  participants  had  prior  involvement  with  the 
1994  OTA  security  and  privacy  report,  as  advisory  panel  mem¬ 
bers  for  the  assessment,  workshop  participants,  and/or  reviewers. 


1  U.S.  Congress,  Office  of  Technology  Assessment,  Information  Security  and  Privacy 
in  Network  Environments,  OTA-TCT-606  (Washington,  DC:  U.S.  Government  Printing  |  65 

Office,  September  1994). 
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The  workshop  participants  also  served  as  exter¬ 
nal  reviewers  for  this  background  paper.  The 
workshop  participants  do  not,  however,  necessar¬ 
ily  approve,  disapprove,  or  endorse  this  back¬ 
ground  paper.  OTA  assumes  full  responsibility 
for  the  background  paper  and  the  accuracy  of  its 
contents. 

One  workshop  objective  was  to  gauge  partici¬ 
pants’  overall  reactions  to  the  1994  OTA  report  on 
security  and  privacy.  Another  objective  was  to 
identify  related  topics  that  merited  attention  and 
that  OTA  had  not  already  addressed  (e.g.,  network 
reliability  and  survivability,  or  “corporate”  pri¬ 
vacy — see  below).  However,  the  intent  of  the 
workshop  was  not  to  rehash  the  issues  and  contro¬ 
versies  described  in  the  report,  but  rather  to  build 
on  the  report  and  push  beyond  it.  A  goal  for  the 
workshop  was  for  participants  to  identify — as 
specifically  as  possible — areas  ripe  for  congres¬ 
sional  action. 

To  spark  their  thinking  and  help  focus  the  day’s 
discussion,  participants  received  a  set  of  discus¬ 
sion  topics  and  questions  in  advance  (see  box  3-1), 
along  with  a  copy  of  the  1994  report.  The  general 
areas  of  interest  were: 

1 .  the  marketplace  for  information  safeguards  and 
factors  affecting  supply  and  demand; 

2.  information-security  “best  practices”  in  the  pri¬ 
vate  sector,  including  training  and  implementa¬ 
tion,  and  their  applicability  to  government 
information  security; 

3.  the  impacts  of  federal  information-security  and 
policies  on  business  and  the  public;  and 

4.  desirable  congressional  actions  and  suggested 
time  frames  for  any  such  actions. 

The  spirited  and  lively  workshop  discussion 
identified  linkages  among  a  wide  variety  of  the 
topics  and  questions  posed  by  OTA.  The  range  of 
discussion  included  cryptography  policies  (espe¬ 
cially  export  controls  on  cryptography),  informa¬ 
tion  security  in  the  private  sector,  privacy 
protections,  safeguarding  proprietary  information 
and  intellectual  property,  and  business  needs  in 
the  international  marketplace. 

OTA  has  identified  some  themes  from  the  day’s 
discussion  that  have  particular  significance,  espe¬ 


cially  in  the  context  of  current  developments,  for 
congressional  consideration  of  information-secu¬ 
rity  issues  and  options  identified  in  the  1994  OTA 
report.  These  themes,  which  are  explored  in  chap¬ 
ter  4  of  this  background  paper,  include: 

■  the  mismatch  between  the  domestic  and  in¬ 
ternational  effects  of  current  U.S.  export  con¬ 
trols  on  cryptography  and  the  needs  of  business 
and  user  communities  in  an  international  econ¬ 
omy; 

■  the  intense  dissatisfaction  on  the  part  of  the  pri¬ 
vate  sector  with  the  lack  of  openness  and  prog¬ 
ress  in  resolving  cryptography-policy  issues; 

■  the  mismatch  between  the  federal  standards 
process  for  cryptography-related  federal  in¬ 
formation  processing  standards  (FIPS)  and  pri¬ 
vate  sector  needs  for  exportable,  cost-effective 
safeguards; 

■  the  mismatch  between  the  intent  of  the  Com¬ 
puter  Security  Act  and  its  implementation; 

■  the  distinction  between  security  policies  and 
guidelines  for  implementing  these  policies; 

■  the  need  for  technological  flexibility  in  imple¬ 
menting  security  policies;  and 

■  the  need  for  line  management  accountability 
for,  and  commitment  to,  good  security,  as  op¬ 
posed  to  “handing  off’  security  to  technology 
(i.e.,  hoping  that  a  “technological  fix”  will  be 
a  cure-all). 

The  remainder  of  this  chapter  highlights  major 
points  and  opinions  expressed  by  the  workshop 
participants,  while  attempting  to  convey  a  sense 
of  the  variety  of  positions  propounded.  It  is  impor¬ 
tant  to  note  that  this  presentation  is  not  intended  to 
represent  conclusions  reached  by  the  participants; 
moreover,  the  reader  should  not  infer  any  general 
consensus,  unless  consensus  is  specifically  noted. 

I  Cryptography  Policy 
and  Export  Controls 

The  need  for  reform  of  export  controls  was  the 
number  one  topic  at  the  workshop  and  perhaps  the 
only  area  of  universal  agreement.  Participants  ex¬ 
pressed  great  concern  that  the  current  controls  are 
impeding  companies’  implementation  of  good  se¬ 
curity  in  worldwide  operations  and  harming  U.S. 
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BOX  3-1 :  Areas  of  Inquiry  for  Workshop 


The  marketplace  for  information  safeguards  (supply  and  demand) 

.What  factors  and  considerations  affect  the  demand  for  and  supply  of  safeguard  tools? 

•With  respect  to  personal  privacy,  are  database  owners/custodians  and  information  system  administra¬ 
tors  sufficiently  willing  and  able  to  protect  privacy? 

.Is  there  a  market  failure  that  requires  government  intervention? 

Information-security  “best  practice,”  training,  and  technology  tools 

•What  is  the  state  of  “best  practice”  in  information  security  (and  implications  for  agencies  and  Office  of 
Management  and  Budget  guidance)? 

•Security  training  and  awareness. 

.Technology  tools  for  securing  networks  and  data. 

Impacts  of  federal  policies  -i  busiiv  «  and  the  public 

•What  is  the  likely  impact  of  federal  policies  and  initiatives  on  business?  On  agency  operations  and  in¬ 
teractions  with  the  private  sector? 

.  Impact  of  cryptography  policies  on  business. 

.Electronic  commerce  and  contracts. 

What  should  Congress  do-and  when? 

.Prioritization  of  problem  areas  or  needs  identified  in  discussion. 

.  Is  there  a  possible  problem  of  “having  the  tail  wag  the  dog”? 

.What  are  specific  solutions  for  high-priority  problems/needs? 


firms’  competitiveness  in  the  international  mar¬ 
ketplace.  More  than  one  participant  considered 
that  what  is  really  at  stake  is  loss  of  U.S.  leader¬ 
ship  in  the  information  technology  industry.  As 
one  participant  put  it,  the  current  system  is  “a  mar¬ 
ket  intervention  by  the  govemmer.  with  unin¬ 
tended  bad  consequences  for  both  government 
and  the  private  sector.” 

U.S.  export  policy  restrictions  on  products  im¬ 
plementing  the  Data  Encryption  Standard  (DES) 
and/or  the  Rivest-Shamir-Adleman  (RSA)  algo¬ 
rithm  are  viewed  by  several  participants  as  anti¬ 
competitive  and  likely  to  stall  U.S.  information 
technology,  because  they  frustrate  both  the  mul¬ 
tinational  companies’  need  to  communicate  se¬ 
curely  worldwide  and  the  U.S.  vendors  who 
furnish  secure  communication  products.  Multina¬ 
tionals  are  forced  to  go  elsewhere  and  have  suppli¬ 
ers  build  for  them  abroad,  while  U.S.  vendors  face 
an  artificially  limited  market.  (These  products  can 


then  be  used  overseas  and  also  be  imported  for  use 
in  the  United  States.) 

Several  participants  asserted  that  U.S.  export 
controls  have  failed  at  preventing  the  spread  of 
cryptography,  because  DES-  and  RSA-based  en¬ 
cryption,  among  others,  are  available  outside  of 
this  country.  They  noted  that  the  only  “success”  of 
the  controls  has  been  to  prevent  major  U.S.  soft¬ 
ware  companies  from  incorporating  high-quality, 
easy-to-use,  integrated  cryptography  in  their 
products.  Many  participants  also  viewed  export 
controls  as  the  single  biggest  obstacle  to  establish¬ 
ing  international  standards  for  information  safe¬ 
guards;  one  noted  the  peculiarity  of  picking  a 
national  standard  and  then  trying  to  restrict  its  use 
internationally. 

Participants  also  expressed  frustration  with  the 
lack  of  a  timely,  open,  and  productive  dialogue  be¬ 
tween  government  and  the  private  sector  on  cryp¬ 
tography  issues  and  the  lack  of  response  by 
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government  to  what  dialogue  has  taken  place.2 
Many  stressed  the  need  for  a  genuine,  open  dia¬ 
logue  between  government  and  business,  with 
recognition  that  business  vitality  is  a  legitimate 
objective.  Participants  noted  the  need  for  Con¬ 
gress  to  broaden  the  policy  debate  about  cryptog¬ 
raphy,  with  more  public  visibility  and  more 
priority  given  to  business  needs  and  economic 
concerns.  In  the  export  control  arena,  Congress 
was  seen  as  having  an  important  role  in  getting 
government  and  the  private  sector  to  converge  on 
some  feasible  middle  ground  (legislation  would 
not  be  required,  if  export  regulations  were 
changed).  Leadership  and  timeliness  (“the  prob¬ 
lem  won’t  wait”)  were  viewed  as  priorities,  rather 
than  more  studies  and  delay. 

Some  participants  also  noted  the  importance  of 
increased  oversight  of  the  Computer  Security  Act 
of  1987  (Public  Law  100-235),  as  well  as  possible 
redirection  of  National  Institute  of  Standards  and 
Technology  (NIST)  activities  (e.g.,  collecting  in¬ 
formation  about  what  industry  is  doing,  pointing 
out  commonalities  and  how  to  interoperate,  rather 
than  picking  out  a  “standard”). 

INFORMATION  SECURITY  IN 
THE  PRIVATE  SECTOR 

The  workshop  discussion  emphasized  active  risk 
acceptance  by  management  and  sound  security 
policies  as  key  elements  of  good  information-se¬ 
curity  practice  in  the  private  sector.  The  concept  of 
management  responsibility  and  accountability  as 
integral  components  of  information  security,  rath¬ 
er  than  just  “handing  off’  security  to  technology, 
was  noted  as  very  important  by  several  partici¬ 
pants.  Sound  security  policies  as  a  foundation  for 
good  practice  were  described  as  technology  neu¬ 
tral,  consistent  across  company  cultures,  mini¬ 
malist,  and  as  absolutes.  Much  was  made  of 
technology-neutral  policies  because  properly  ap¬ 
plied,  they  do  not  prescribe  implementations,  are 
not  easily  obsoleted  by  changes  in  technology  or 
business  practices,  and  allow  for  local  customiza¬ 


tion  of  implementations  to  meet  operational  re¬ 
quirements. 

I  Information-Security  Policies 
and  "Best  Practices" 

There  was  general  agreement  that  direct  support 
by  top  management  (e.g.,  the  chief  executive  offi¬ 
cer  and  board  of  directors  of  a  corporation)  and  up¬ 
per-management  accountability  are  central  to 
successful  implementation  of  security  policy. 
Many  participants  felt  that  tying  responsibility  for 
the  success  of  security  policies — and  for  the  con¬ 
sequences  of  security  incidents — to  upper  man¬ 
agement  is  critical.  Many  considered  it  vital  that 
the  managers  not  be  insulated  from  risk.  Accord¬ 
ing  to  one  participant,  it  is  important  to  educate 
managers  on  active  risk  acceptance;  another  sug¬ 
gested  that  their  divisions  could  be  held  financial¬ 
ly  responsible  for  lost  information. 

In  some  of  the  companies  represented,  security 
policy  has  been  refined  to  the  point  of  “Thou  shalt 
...  not  how  thou  shalt.”  Security  managers  are 
charged  with  developing  something  resembling 
the  “Ten  Commandments”  of  security.  Important¬ 
ly,  these  are  not  guidelines  for  implementation. 
Rather,  they  are  “minimalist”  directives  that  out¬ 
line  what  must  happen  to  maintain  information  se¬ 
curity,  but  not  how  it  must  be  achieved. 

One  of  the  most  important  aspects  about  these 
policies  is  that  they  are  consistent  across  the  entire 
company;  regardless  of  the  department,  informa¬ 
tion-security  policies  are  considered  universally 
applicable.  The  policies  have  to  be  designed  in  a 
broad  enough  fashion  to  ensure  that  all  company 
cultures  will  be  able  to  comply.  Broad  policy  out¬ 
lines  allow  information  to  flow  freely  between 
company  divisions  without  increased  security 
risk. 

The  workshop  discussion  noted  the  importance 
of  auditing  security  implementation  against 
policy,  not  against  implementation  guidelines. 
Good  security  policies  must  be  technology  neu¬ 
tral,  so  that  technology  upgrades  and  different 


2  See  ibid.,  pp.  11-13,  150-160,  and  174-179. 
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equipment  in  different  divisions  would  not  affect 
implementation.  Ensuring  that  policies  are  tech¬ 
nology-neutral  helps  prevent  confusing  imple¬ 
mentation  techniques  and  tools  (e.g.,  use  of  a 
particular  type  of  encryption  or  use  of  a  computer 
operating  system  with  a  certain  rating)  with  policy 
objectives,  and  discourages  “passive  risk  accep¬ 
tance”  like  mandating  use  of  a  particular  tech¬ 
nology.  This  also  allows  for  flexibility  and 
customization. 

Workshop  participants  noted  that,  although  the 
state  of  practice  in  setting  security  policy  often  has 
not  lived  up  to  the  ideals  discussed  above,  many 
companies  are  improving.  At  this  point  there  are 
several  roadblocks  frustrating  more  robust  securi¬ 
ty  for  information  and  information  systems.  The 
primary  roadblock  is  cost.  Many  systems  are  not 
built  with  security  in  mind,  so  the  responsibility 
falls  on  the  end  user  and  retrofitting  a  system  with 
security  can  be  prohibitively  expensive. 

Availability  of  Secure  Products 

The  question  of  the  availability  of  secure  products 
generated  some  disagreement  over  whether  the 
market  works  or,  at  least,  the  extent  to  which  it 
does  and  does  not  work.  As  described  above,  there 
was  consensus  that  export  controls  and  other  gov¬ 
ernment  policies  that  segmented  market  demand 
were  undesirable  interventions.  Though  the  feder¬ 
al  government  can  use  its  purchasing  power  to  sig¬ 
nificantly  influence  the  market,  most  participants 
felt  that  this  sort  of  market  intervention  would  not 
be  beneficial  overall.  Many  felt  the  market  will 
develop  security  standards  and  secure  systems  if 
left  to  its  own  devices;  others  took  issue  with  this 
position. 

Some  participants  said  there  are  problems  in 
the  marketplace.  They  asserted  that  many  comput¬ 
er  products  are  not  designed  with  security  in  mind 
and  cannot  be  made  secure  easily  or  cheaply.  In 
particular,  the  UNIX  operating  system  and  the  In¬ 
ternet  architecture  were  cited  as  examples  of  prod¬ 
ucts  designed  without  “built-in”  security.  Some 
suggested  that  today’s  fierce  price  competition 
forces  product  vendors  to  disregard  security  fea¬ 
tures  in  favor  of  cost  savings,  leaving  the  purchas¬ 


er  to  add  security  to  the  system  retroactively,  at  a 
much  higher  cost. 

The  perceived  propensity  for  security  to  be  def¬ 
erred  in  order  to  cut  costs  had  one  or  two  partici¬ 
pants  questioning  the  ability  of  the  market  to 
develop  reasonably  priced  secure  products  for  in¬ 
formation  systems  and  whether  government  ac¬ 
tion  is  needed  to  lead  the  market  in  the  “right” 
direction — for  example,  through  standards  for 
federal  procurements  or  regulations  setting  base¬ 
line  product  requirements.  Though  most  partici¬ 
pants  seemed  to  agree  that  many  products  have 
been  built  without  security  features  and  that  retro¬ 
fitting  a  system  with  security  is  expensive  and  dif¬ 
ficult,  there  was  strong  sentiment  from  industry 
representatives  that  the  market  should  be  left 
alone.  Many  participants  described  government 
interventions  into  the  market,  such  as  export  con¬ 
trols  and  the  Escrowed  Encryption  Standard 
(EES,  or  Clipper),  as  economically  detrimental, 
and  saw  nothing  to  indicate  that  interventions 
would  be  more  beneficial  in  the  future. 

Some  pointed  out  a  distinction  between  the 
ability  of  large  businesses  and  small  businesses  to 
purchase  products  that  incorporate  security.  Large 
businesses  are  able  to  demand  more  security  fea¬ 
tures  because  of  the  size  of  their  operations;  while 
smaller  companies  must  often  individually  pur¬ 
chase  and  configure  a  basic  product,  which  may 
have  been  designed  without  security  in  mind. 

Implicit  in  the  discussion  of  the  ability  of  the 
market  to  produce  secure  products  is  the  extent  of 
demand  for  them.  Those  arguing  that  market 
forces  will  develop  secure  systems  stated,  basical¬ 
ly,  that  when  buyers  demand  secure  products,  se¬ 
cure  products  will  be  available.  Participants  from 
vendor  companies  were  especially  adamant  about 
the  strength  of  the  relationship  between  them¬ 
selves  and  the  industry  users.  (One  example  of 
user  efforts  to  work  with  vendors  to  develop  more 
security-oriented  products  is  a  group  called  Open 
User  Recommended  Solutions  (OURS),  which 
has  recently  developed  a  single  sign-on  product 
description.)  Those  who  felt  the  market  will  not 
develop  secure  products  in  the  near  future  feel  that 
the  demand  for  inexpensive  products  will  con- 
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tinue  to  outweigh  demand  for  security,  and/or 
noted  the  demand-segmenting  effects  of  export 
controls. 

Some  participants  pointed  out  that  the  reason 
security  concerns  defer  to  price  concerns  is  the  in¬ 
ability  to  quantify  the  value  of  good  security. 
Some  noted  this  as  a  prevalent  problem  when  at¬ 
tempting  to  convince  upper  management  of  the 
need  for  security.  Lack  of  reported  breaches,  the 
inability  to  evaluate  successful  security,  and  the 
lack  of  a  direct  cost/benefit  analysis  all  lead  to  an 
unclear  assessment  of  need.  This  in  turn  reduces 
the  demand,  which  drives  the  market  to  ignore  se¬ 
curity. 

Training 

Most  security  managers  participating  in  the  work¬ 
shop  viewed  training  as  vital  to  any  successful  in- 
formation-security  policy.  Lack  of  training  leads 
to  simple  errors  potentially  capable  of  defeating 
any  good  security  system — for  example,  em¬ 
ployees  who  write  their  passwords  on  paper  and 
tape  it  to  their  computers.  Several  participants 
knew  of  companies  that  have  fallen  into  the 
technology  trap  and  have  designed  excellent  com¬ 
puter  security  systems  without  sufficiently  em¬ 
phasizing  training. 

There  is  a  core  of  training  material  that  is 
technology  neutral  and  ubiquitous  across  the  com¬ 
pany.  Some  companies  develop  elaborate  video 
presentations  to  ensure  that  training  is  consistent 
throughout  the  various  company  cultures.  Some 
participants  felt  that  employees  must  be  trained  in 
technology;  believing  that,  if  users  do  not  under¬ 
stand  the  technologies  they  have  incorporated  into 
their  business,  then  they  will  be  pressed  to  do  what 
is  necessary  to  implement  security  policies. 

The  necessity  for  impressing  upon  employees 
their  role  in  information  security  is  paramount. 
Because  the  average  individual  tends  to  not  recog¬ 
nize  the  importance  of  training,  it  falls  to  manage¬ 
ment  to  demonstrate  its  value.  To  this  end,  several 
participants  emphasized  the  importance  of  dem¬ 
onstrating  the  value  of  training  to  management. 


Many  felt  that  much  of  the  responsibility  for  get¬ 
ting  management  interested  in  training  rested  with 
the  program  manager.  Like  other  elements  of  in¬ 
formation  security,  financial  departments  have 
difficulty  quantifying  the  value  of  training.  Some 
point  out  that  “an  insurance”  policy  is  a  poor  mod¬ 
el,  because  there  are  no  guarantees,  nor  are  the 
risks  easily  quantifiable.  Some  suggested  it  will 
take  a  crisis  to  convince  upper  management  of  the 
need  to  effectively  train  employees  and  that  anec¬ 
dotal  evidence  is  the  best  tool  in  the  absence  of 
hard  definable  numbers.  This  view  was  not  uni¬ 
versally  accepted. 

Common  Themes 

A  common  thread  to  the  discussion  of  informa¬ 
tion-security  practices  is  the  necessity  for  a 
heightened  awareness  of  security  needs  by  upper 
management.  Making  management  aware  of  the 
danger  of  and  propensity  for  financial  loss  due  to 
lax  security  is  vital  to  security  policy,  product 
availability,  and  the  training  issue.  Some  partici¬ 
pants  felt  that  the  inability  to  set  up  a  cost  justifica¬ 
tion  formula  for  information  security  is  a  major 
impediment  to  convincing  management  of  the 
need  for  it.  In  addition,  the  difficulty  in  evaluating 
the  success  of  a  security  program  limits  a  security 
officer  in  making  a  case  to  management. 

A  proposed  solution  to  this  problem  is  the  es¬ 
tablishment  of  an  agreed-upon  body  of  knowledge 
or  “common  checklist”  for  security  officers  to 
compare  their  company  policies  against.  There  is 
a  large  core  of  commonality  in  security  awareness, 
training,  and  education.  If  made  legally  binding, 
or  part  of  industry  consensus  as  to  what  consti¬ 
tutes  “prudent  practice,”  such  a  checklist  would 
also  tie  directly  into  the  liability  issues  as  well  as  a 
host  of  other  problems  facing  companies.  For  ex¬ 
ample,  when  organizations  outsource,  contractual 
specifications  are  needed  to  ensure  adequate  secu¬ 
rity  coverage.  If  there  were  a  well-known  and  ac¬ 
cepted  “common  checklist”  for  security,  then  it 
would  be  easier  to  develop  contractual  specifica- 
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tions  without  revealing  too  much  of  your  opera¬ 
tions  or  levels  of  security  to  the  contractor. 

I  Domestic  and  International 
Privacy  Issues 

Consumers  are  increasingly  concerned  with  con¬ 
trol  of  personal  and  transactional  data  and  are 
seeking  some  protection  from  potential  abuse  of 
this  information.  Those  participants  who  had  been 
less  inclined  than  most  to  trust  the  market  on  secu¬ 
rity  issues  found  more  comfortable  ground  on  pri¬ 
vacy,  because  few  participants  seemed  to  feel  that 
the  market  will  prioritize  personal  privacy. 

The  discussion  of  privacy  protection  was  less 
extensive  than  some  other  topics  covered  during 
the  workshop.  Opinions  were  split  on  whether 
new  privacy  legislation  and/or  a  privacy  commis¬ 
sion  was  desirable.  There  was  a  general  feeling 
that  individuals  should  be  protected  from  abuses 
incurred  by  access  to  their  personal  data  (e.g., 
transactional  data  or  “data  shadows”  that  could  be 
reused  or  sold  like  a  subscribers  list),  but  many 
were  concerned  about  limiting  business  opportu¬ 
nities  through  new  controls. 

Some  participants  pointed  out  that  the  global¬ 
ization  of  the  information  infrastructure  will  in¬ 
crease  consumer  privacy  concerns  and  present 
security  questions  (e.g.,  nonrepudiation  of  trans¬ 
actions)  in  home-based  applications.  One  partici¬ 
pant  recommended  a  close  reading  of  the 
Canadian  privacy  policy  as  a  possible  guide  for 
our  government.3  The  concepts  of  a  Privacy  Com¬ 
mission  or  a  privacy  “Bill  of  Rights”  were  also 
brought  up  as  omnibus  solutions,  but  specifics  re¬ 
garding  how  they  might  protect  personal  privacy 
were  not  examined. 

One  of  the  umbrella  points  of  the  privacy  de¬ 
bate  that  most  participants  agreed  to  is  the  need  for 
a  “trusted”  infrastructure  capable  of  supporting 


global  transactions  and  trade  based  on  a  firm  set  of 
ground  rules  and  fair  information  practices.  This 
trusted  infrastructure  must  support  authentication 
and  allow  secure  transactions.  To  be  implemented 
such  an  infrastructure  will  have  to  resolve  liabil¬ 
ity4  and  conditional  access  issues  and  develop  a 
system  of  certification  controls.  Today,  differ¬ 
ences  between  the  levels  of  privacy  protection  in 
the  United  States  and  those  of  its  trading  partners, 
which  in  general  protect  privacy  more  rigorously, 
could  also  inhibit  development  of  this  infrastruc¬ 
ture. 

Some  participants  felt  that  the  common  rules  of 
the  road  for  a  trusted  infrastructure  could  be  the  re¬ 
sponsibility  of  a  U.S.  Privacy  Commission.  Many 
of  these  felt  that  a  close  look  at  the  European  pri¬ 
vacy  system  would  be  helpful  in  establishing 
guidelines  (being  the  “last  ones  on  the  block”  to 
open  a  Privacy  Commission,  the  United  States 
should  not  try  to  set  the  standard,  but  should  build 
on  the  European  Union  model).  Unfortunately, 
one  participant  noted,  this  is  a  20-year-old  discus¬ 
sion,  and  as  much  as  industry  would  like  a  com¬ 
mon  set  of  rules  with  the  European  Union,  he  felt 
that  it  is  unlikely  they  will  get  it  in  the  near  future. 

I  Proprietary  Information  and 
Intellectual  Property 

A  major  concern  raised  by  industry  participants 
was  the  need  to  protect  intellectual  property  and 
proprietary  information  in  electronic  form.  Com¬ 
panies  need  to  protect  their  information  and  trans¬ 
mit  it  to  business  partners  and  offices  here  and 
abroad.  In  light  of  what  many  perceived  as  a  grow¬ 
ing  problem,  several  individuals  recommended  a 
reexamination  of  “information  rights”  (e.g.,  intel¬ 
lectual  property  rights,  confidentiality  for  propri¬ 
etary  information)  in  light  of  the  recent  changes  in 
information  storage  and  data  collection  methods 


3  See  Industry  Canada,  Privacy  and  the  Canadian  Information  Highway  (Ottawa,  Ontario:  Minister  of  Supply  and  Services  Canada,  1994), 
available  by  WWW  from  http://debra.dgbt.doc.ca/isc/isc.html.  See  also  Canadian  Standards  Association,  “Model  Code  for  the  Protection  of 
Personal  Information,”  CAN/CSA-Q830-1994,  draft,  November  1994. 

4  For  a  discussion,  see  Michael  S.  Baum,  Federal  Certification  Authority  Liability  and  Policy,  NIST-GCR-94-654,  NTIS  Doc.  No. 
PB94-191-202  (Springfield,  VA:  National  Technical  Information  Service,  1994). 
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that  allow  information  to  be  readily  copied,  aggre¬ 
gated,  and  manipulated. 

Some  participants  felt  that  confidentiality  of 
company  information  could  be  adequately  ad¬ 
dressed  with  better  corporate  security  policies. 
For  example,  it  may  be  more  difficult  to  prosecute 
(or  deter)  an  intruder  if  a  company’s  log-on  screen 
says  “Welcome  to  Company  X”  instead  of  provid¬ 
ing  a  clear  statement  to  inform  individuals  of  the 
company’s  intent  to  prosecute  if  information  on 
the  system  is  misused  or  accessed  without  autho¬ 
rization. 

Several  participants  raised  the  issue  of  “corpo¬ 
rate  privacy”  regarding  to  information  not  pro¬ 
tected  by  intellectual  property  laws.  Many  felt 
corporations  need  legal  protection  for  “private” 
information — that  is,  information  that  is  propri¬ 
etary  to  the  corporation,  but  does  not  qualify  for 
protection  under  copyright,  patent,  or  trade  secret 
laws.5  Though  some  privacy  advocates  balk  at  the 
concept  of  “corporate  privacy,”6  several  partici¬ 
pants  felt  that  a  set  of  standards  protecting  re¬ 
search  and  other  proprietary  information  were 
important  to  both  information  security  and  contin¬ 
ued  product  development.  The  issue  of  “corporate 
privacy”  was  also  raised  regarding  legal  discov¬ 
ery.  A  few  individuals  expressed  concern  over  the 
expense  corporations  face  complying  with  dis¬ 
covery  motions  during  litigation  (e.g.,  with  re¬ 
spect  to  email  and  electronic  records),  but  this 
topic  was  not  explored  at  length  during  the  day’s 
discussion. 


Patent  issues  and  confidentiality  of  lab  docu¬ 
ments  were  of  major  concern  to  individuals  in¬ 
volved  in  research  and  development.  They  saw  a 
need  for  evidentiary  rules  in  electronic  environ¬ 
ments  to  prevent  research  fraud,  to  ensure  that 
electronic  lab  notebooks  are  a  permanent,  enforce¬ 
able  record,  and  to  prosecute  intruders. 

There  was  some  discussion  regarding  whether 
new  laws  are  needed  to  protect  information  re¬ 
sources  from  computer  crime — or  whether  better 
enforcement  is  the  solution.  Some  felt  that  the  le¬ 
gal  system  is  not  in  tune  with  the  new  world  of 
computer  crime;  a  world  where  the  computer  is 
the  instrument  not  the  target  of  the  crime.  Some 
also  felt  that  the  legal  profession  may  not  be  famil¬ 
iar  with  “authentication”  in  electronic  environ¬ 
ments.  Others  felt  that  enforcement  is  the 
problem,  not  the  laws.  This  topic  was  not  ex¬ 
amined  at  length  and  no  consensus  was  reached. 

The  question  of  liability  standards  for  a  compa¬ 
ny  in  possession  of  personal  data  was  brought  up 
as  an  issue  in  need  of  a  solution.  One  participant 
made  an  urgent  plea  for  a  rapid  definition  of  basic 
legal  requirements,  to  prevent  costly  retrofitting 
to  meet  security  and  privacy  requirements  that 
could  be  imposed  later  on.  Some  believe  there 
should  be  true  and  active  participation  at  the  feder¬ 
al,  state,  and  local  levels  to  develop  consensus  on 
new  principles  of  “fair  information  practices”7 
that  would  take  into  account  the  ways  businesses 
operate  and  be  flexible  enough  to  meet  the  needs 


5  George  B  Trubow,  Whether  and  Whither  Corporate  Privacy ,  essay  based  on  an  article  prepared  for  the  “DataLaw  Report”  Gtru- 
bow@jmls.edu. 

6  “The  scope  of  these  laws  should  be  limited  to  the  protection  of  the  privacy  of  personal  information;  they  should  not  be  extended  to  cover 
legal  persons.  Issues  relating  to  companies,  such  as  providing  adequate  protection  for  corporate  proprietary  information,  are  different  and 
should  be  the  subject  of  a  different  body  of  law.”  (Business  Roundtable,  “Statement  on  Transborder  Data  Flow — on  Privacy  and  Data  Protec¬ 
tion,”  in  L.  Richard  Fischer  (ed.),  The  Law  of  Financial  Privacy,  A  Compliance  Guide ,  2nd  Ed.  (New  York,  NY:  Warren,  Gorham  &  Lamont, 
1991),  appendix  6.3,  p.  6-93.) 

7  For  example,  the  Privacy  Act  of  1974  (Public  Law  93-579)  embodied  principles  of  fair  information  practices  set  forth  in  Computers  and 
the  Rights  of  Citizens,  a  report  published  in  1973  by  the  former  U.S.  Department  of  Health,  Education,  and  Welfare.  Those  principles  included 
the  requirement  that  individuals  be  able  to  discover  what  personal  information  is  recorded  about  them  and  how  it  is  used,  as  well  as  be  able  to 
correct  or  amend  information  about  themselves.  Other  principles  included  the  requirement  that  organizations  assure  the  reliability  of  personal 
data  for  its  intended  use  and  take  reasonable  precautions  to  prevent  misuse.  The  Privacy  Act  is  limited  to  government  information  collection  and 
use.  It  approaches  privacy  issues  on  an  agency-by-agency  basis  and  arguably  does  not  address  today’s  increased  computerization  and  linkage 
of  information.  See  OTA,  op.  cit.,  footnote  1,  ch.  3. 
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of  various  types  of  individuals  and  organizations, 
but  that  would  also  offer  some  stability  (or,  “safe 
havens”)  for  new  lines  of  business  by  delineating 
acceptable  forms  of  information  collection  and 
use.  Others  did  not  see  a  need  for  omnibus  privacy 
codes  or  legislation,  preferring  to  deal  with  prob¬ 
lems  on  an  industry-by-industry  basis. 

As  part  of  the  question  of  liability,  it  was  noted 
that  the  tension  between  network  providers  and 
users  continues  to  be  unresolved.  The  dilemma 
exists  between  the  network  providers’  inability  to 
monitor  content  (e.g.,  invasion  of  privacy),  while 
at  the  same  time  being  held  responsible  for  the 
content  of  material  transferred  over  their  services. 
One  suggestion  was  to  treat  network  providers 
more  like  public  utilities  and  less  like  publishers. 

I  Views  on  Congressional  Action 

This  section  outlines  suggestions  made  for  gov¬ 
ernment  action,  particularly  by  Congress.  It  does 
not  represent  the  consensus  of  the  participants  at 
the  workshop;  it  only  isolates  areas  that  were  dis¬ 
cussed  and  lists  possible  solutions  generated  dur¬ 
ing  the  discussion. 

Cryptography  Policy  and  Export  Controls 

A  near  consensus  was  reached  regarding  the  EES 
(Clipper  chip).  The  vast  majority  felt  that  it  was 
poorly  handled,  poorly  conceived,  and  did  not 
take  into  account  the  structure  of  today’s  world 
economy.  It  is  a  national  standard  in  an  interna¬ 
tional  economy.  It  will  exacerbate  the  problems 
with  export  controls,  by  having  one  system  (EES) 
in  the  United  States  and  one  system  (DES  or 
another  system)  outside  the  United  States.  Many 
felt  that  it  is  an  enormous  distraction  that,  coupled 
with  export  controls,  will  allow  foreign  countries 
to  get  ahead  of  us  in  the  global  information  infra¬ 
structure. 

Several  participants  felt  that  the  United  States 
is  getting  out  of  step  with  the  international  com¬ 
munity,  and  appears  pointed  in  the  wrong  direc¬ 
tion  on  information  security.  Many  industry 
representatives  feel  that  the  potential  of  U.S.  poli¬ 
cies  to  damage  the  economy  and  U.S.  industry  is 


not  being  given  priority  by  the  people  making  de¬ 
cisions. 

Possible  Congressional  Actions: 

■  Review  export  controls  and  find  a  feasible 
middle  ground. 

■  Review  the  executive  decision  on  the  Clipper 
chip. 

■  Promote  consumer  use  of  a  public-key  infra¬ 
structure. 

■  Open  up  a  public  dialogue  with  NIST,  the  Na¬ 
tional  Security  Agency  (NSA),  and  the  Federal 
Bureau  of  Investigation  (FBI)  on  the  interna¬ 
tional  availability  of  cryptography. 

■  State  that  the  international  competitiveness  of 
the  United  States  in  information  systems  and 
communications  is  a  priority  in  considering 
cryptography  policy. 

Federal  Standards  and  Open  Dialogue 

There  was  a  general  consensus  on  the  need  for 
ground  rules  and  standards  for  safeguarding  in¬ 
formation,  but  much  disagreement  on  how  this 
should  be  done.  There  was  sentiment  that  leader¬ 
ship  is  needed  from  the  government  on  these  is¬ 
sues.  However,  many  participants  did  not  think 
the  government  should  or  could  set  these  stan¬ 
dards.  Many  felt  the  information-policy  branches 
of  the  government  are  unable  to  respond  adequate¬ 
ly  to  the  current  leadership  vacuum;  therefore, 
they  felt  that  government  should  either  establish  a 
more  effective  policy  system  and  open  a  construc¬ 
tive  dialogue  with  industry  or  leave  the  problem  to 
industry. 

The  lack  of  public  dialogue,  visibility,  and  ac¬ 
countability,  particularly  demonstrated  by  the 
introduction  of  the  Clipper  chip  and  promulgation 
of  the  EES,  is  a  constant  source  of  anger  for  both 
industry  representatives  and  public  interest 
groups. 

There  were  many  concerns  and  frustrations 
about  the  role  of  the  National  Security  Agency. 
Several  individuals  felt  that  dialogue  on  informa¬ 
tion  policy  is  paralyzed  because  NSA  is  not  allow¬ 
ing  open  discussion  nor  responding  in  any 
tangible  way  to  the  needs  of  industry.  Many  par- 
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ticipants  suggested  that  this  country  desperately 
needs  a  new  vision  of  national  security  that  incor¬ 
porates  economic  vitality.  They  consider  that 
business  strength  is  not  part  of  NSA’s  notion  of 
“national  security,”  so  it  is  not  part  of  their  mis¬ 
sion.  As  one  participant  put  it,  “saying  that  ‘we  all 
have  to  be  losers’  on  national  security  grounds  is 
perverse  industrial  policy.” 

The  Computer  Systems  Security  and  Privacy 
Board  (CSSPAB)  was  suggested  as  one  stimulus 
for  generating  dialogue  between  industry  and 
government,  but  according  to  several  participants 
the  committee  is  not  well  utilized.  In  addition, 
there  exists  an  information  gap:  the  CSSPAB  was 
“kept  in  the  dark”  about  the  Clipper  initiative, 
then  after  it  gathered  information  through  public 
meetings,  the  information  and  CSSPAB  recom¬ 
mendations  were  ignored  by  the  Commerce  De¬ 
partment. 

Possible  Congressional  Actions: 

■  Define  basic  legal  requirements  to  prevent  un¬ 
necessary  and  retroactive  security  measures. 

■  Revise  the  export  administration  act  in  order  to 
allow  multinationals  to  set  up  ubiquitous  secu¬ 
rity  standards  through  U.S.  vendors. 

■  Increase  oversight  of  the  Computer  Security 
Act  as  it  relates  to  the  relationship  between 
NSA  and  NIST  and  review  the  Memorandum 
of  Understanding  between  NSA  and  NIST.  En¬ 
courage  more  open  dialogue  with  and  utiliza¬ 
tion  of  the  CSSPAB. 

■  Encourage  NIST  to  develop  a  Certification 
Standard  to  support  interoperability  across  net¬ 
works,  rather  than  picking  technological  stan¬ 
dards. 

■  Redefine  national  security  priorities. 

Information  Security  in  Federal  Agencies 

Participants  suggested  that  there  needs  to  be  more 
emphasis  on  securing  unclassified  information 
and  that  there  needs  to  be  leadership.  According  to 
some  participants:  the  government  should  get  “its 
house  in  order”  in  the  civilian  agencies;  few 
companies  are  so  badly  managed  as  government 
agencies;  senior  managers  are  unaware  of  respon¬ 
sibilities  and  untrained.  As  a  result,  participants 


noted,  the  architecture  and  policy  constructs  of  the 
international  information  infrastructure  are  being 
developed  right  now,  but  these  are  “being  left  to 
the  technologists”  due  to  lack  of  leadership. 

Several  felt  that  there  has  been  overemphasis 
on  cryptography,  to  the  exclusion  of  management; 
severe  problems  like  errors  and  dishonest  em¬ 
ployees  are  not  addressed  by  this  “technology”  fo¬ 
cus.  Participants  considered  that  the  real  issue  is 
management ;  technology  sloganism  along  the 
lines  of  “buy  C2  [a  computer  security  rating]  and 
you’re  OK”  is  not  enough.  According  to  partici¬ 
pants,  existing  policies  [e.g.,  the  previous  version 
of  OMB  Circular  A-l  30,  Appendix  III]  attempt  to 
mandate  cost-based  models,  but  the  implementa¬ 
tion  is  ineffective.  For  example,  after  the  Comput¬ 
er  Security  Act,  NIST  should  have  been  in  a 
position  to  help  agencies,  but  this  never  happened 
due  to  lack  of  resources.  Civil  agencies  lack 
resources,  then  choose  to  invest  in  new  applica¬ 
tions  rather  than  spend  on  security.  This  is  under¬ 
standable  when  the  observation  that  “nothing 
happens” — that  is,  no  security  incidents  are  de¬ 
tected — is  an  indicator  of  good  security.  Partic¬ 
ipants  observed  that,  if  inspectors  general  of 
agencies  are  perceived  as  neither  rewarding  or 
punishing,  users  get  mixed  signals  and  conclude 
that  there  is  a  mismatch  between  security  postures 
and  management  commitment  to  security  imple¬ 
mentation. 

There  was  widespread  support  for  the  Comput¬ 
er  Security  Act  of  1987,  but  universal  frustration 
with  its  implementation.  NIST,  the  designated 
lead  agency  for  security  standards  and  guidelines, 
was  described  as  underfunded  and  extremely 
slow.  There  was  also  a  general  recognition  that 
people  had  been  complaining  about  NIST  for  a 
while,  but  nothing  has  happened  as  a  result  of 
these  complaints. 

Possible  Congressional  Actions: 

■  Implement  oversight  of  the  Computer  Security 
Act  with  special  attention  to  management  of  in¬ 
formation-security  policy. 

■  Fully  fund  NIST  so  it  can  “sort  out  the  ‘tower 
of  Babel’  in  cryptographic  capabilities  and  sys¬ 
tem  interoperability.”  Several  participants  sug- 
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gested  trying  to  encourage  better  standards 
policy  by  using  the  General  Accounting  Office 
to  audit  agency  compliance  with  NIST  stan¬ 
dards,  or  mandating  that  agencies  respond  to 
CSSPAB  recommendations. 

*  Encourage  more  attention  to  management  prac¬ 
tices.  Review  OMB  Circular  A- 130  with  par¬ 
ticular  emphasis  on  implementation. 

Privacy 

The  privacy  issue  in  general  came  up  often,  but  no 
one  had  a  detailed  solution.  There  is  an  urgent 
sense  that  something  needs  to  be  done,  because 
questions  of  personal  privacy  and  “corporate  pri¬ 
vacy”  continue  to  cause  controversy  and  the  prob¬ 
lems  will  only  increase  as  network  access 
expands.  The  only  concrete  suggestion,  which 
was  not  universally  endorsed,  is  the  creation  of  a 
Privacy  Commission,  possibly  with  a  cabinet-lev¬ 
el  head  or  as  a  part  of  the  Commerce  Department. 

One  frequently  mentioned  topic  was  for  gov¬ 
ernment  recognition  of  U.S.  industry’s  need  for 


consistency  between  U.S.  privacy  laws  and  Euro¬ 
pean  privacy  laws.  This  reflects  the  industry 
orientation  toward  the  international  nature  of  the 
economy. 

Several  participants  called  on  Congress  to  re¬ 
view  liability  issues  and  intellectual-property 
concerns,  with  respect  to  electronic  information 
and  networks.  Some  participants  felt  the  need  to 
protect  providers  from  action  taken  over  their  net¬ 
works.  Some  suggested  that  network  providers  be 
treated  more  like  a  public  utility,  removed  from  li¬ 
ability  for  the  content  of  the  material  carried  over 
their  networks. 

Possible  Congressional  Actions: 

■  Establish  a  Privacy  Commission. 

■  Determine  regulatory  status  and  liability  of  net¬ 
work  providers. 

■  Review  intellectual-property  laws  for  enforce¬ 
ment  in  electronic  environments. 

■  Examine  European  Union  privacy  laws  and  re¬ 
view  the  possibility  of  bringing  U.S.  privacy 
protections  closer  to  theirs. 


This  Page  left  out  original  document 


Implications 

for 

Congressional 

Action 


Since  the  1 994  OTA  report  Information  Security  and  Privacy 
in  Network  Environments 1  was  published,  security  con¬ 
cerns  like  “sniffing”  and  “spoofing”  by  intruders,  security 
holes  in  popular  World  Wide  Web  software,  and  intrusions 
into  commercial  and  government  networks  have  continued  to  re¬ 
ceive  attention: 

■  Password  sniffers  capture  legitimate  users’  passwords  for  later 
use  by  intruders.  Spoofing  involves  the  use  of  fake  origination 
addresses,  so  that  an  incoming  connection  will  appear  to  come 
from  somewhere  else,  usually  a  “legitimate”  or  “trusted”  Inter¬ 
net  network  protocol  (IP)  address.2 
■  The  U.S.  Department  of  Energy’s  computer  security  response 
group  alerted  Internet  users  to,  and  issued  corrections  for,  a 
flaw  in  a  version  of  the  free  UNIX  software  commonly  used  to 
create  World  Wide  Web  “home  pages.”  Depending  on  how  a 
World  Wide  Web  server  is  configured,  the  vulnerability  could 
permit  a  hacker  to  access  the  computer’s  main,  or  “root”  direc¬ 
tory.  Commercial  Web  products  under  development  (e.g.,  for 


1  U.S.  Congress,  Office  of  Technology  Assessment,  Information  Security  and  Priva¬ 
cy  in  Network  Environments ,  OTA-TCT-606  (Washington,  DC:  U.S.  Government  Print¬ 
ing  Office,  September  1994).  See  Congressional  Record,  Sept.  22,  1994,  pp.  SI 3312-13 
(statement  of  Senator  William  V.  Roth,  Jr.  announcing  release  of  the  OTA  report). 

2  See  Michael  Neubarth  et  al.,  “Internet  Security”  (special  section),  Internet  World , 
February  1995,  pp.  31-72.  See  also  William  Stallings,  Network  and  Internetwork  Securi¬ 
ty:  Principles  and  Practice  (Englewood  Cliffs,  NJ:  Prentice  Hall  (IEEE  Press),  1995, 
chapter  6. 
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electronic  commerce)  are  incorporating  addi¬ 
tional  security  features.3 
■  During  1993-94,  the  Defense  Information  Sys¬ 
tems  Agency  (DISA)  conducted  mock  attacks 
on  8,932  Defense  Department  computers.  The 
DISA  team  broke  into  7,860  of  these,  but  the 
systems’  computer  administrators  detected 
only  390  of  the  successful  “sting”  intrusions. 
Only  about  20  reported  the  incident.  DISA  esti¬ 
mates  that  real  attacks  on  Defense  systems  av¬ 
erage  about  one  per  day.4 
The  increasing  prominence  of  the  Defense 
Department’s  “Information  Warfare”  doctrine  is 
raising  awareness  of  threats  from  economic  espio¬ 
nage,  global  organized  crime,  and  terrorism.5 
Awareness  of  technical  countermeasures  like 
firewalls,  active  intrusion-detection  systems,  one¬ 
time  password  generators,  and  challenge-re¬ 
sponse  user  authentication  systems6  continues  to 
rise,  although  use  lags  for  a  number  of  reasons,  in¬ 
cluding  cost.7 

This  chapter  provides  an  update  of  executive 
branch  and  private  sector  cryptography  develop¬ 
ments,  business  perspectives  on  government  poli¬ 
cies,  congressional  consideration  of  privacy 
issues,  and  government-wide  guidance  on  in¬ 
formation  security  in  the  federal  agencies.  It  also 
discusses  the  most  recent  attempts  within  the 
executive  branch  to  centralize  unclassified-in¬ 
formation-security  authorities  government-wide. 


The  proposed  “new  order”  presented  in  the  Secu¬ 
rity  Policy  Board  staff’s  1994  report  (see  below) 
would  increase  the  government-wide  authorities 
of  the  defense  and  intelligence  agencies  for  un¬ 
classified  information  security  within  the  federal 
government.  Such  an  expansion  of  authorities 
would  run  counter  to  the  unclassified-informa¬ 
tion-security  structure  mandated  by  the  Computer 
Security  Act  of  1987  (see  chapter  2  and  appendix 
B),  as  well  as  the  agency  responsibilities  set  forth 
in  the  Paperwork  Reduction  Act  of  1995  (see  be¬ 
low)  and  the  new,  proposed  revision  to  Appendix 
III  of  OMB  Circular  A- 1 30  (see  below).  The  chap¬ 
ter  concludes  with  a  discussion  of  the  implications 
of  these  developments  for  congressional  consider¬ 
ation  of  issues  and  options  identified  in  the  1994 
OTA  report  Information  Security  and  Privacy  in 
Network  Environments. 

UPDATE  ON  CRYPTOGRAPHY 
INITIATIVES 

This  section  highlights  selected  government  and 
commercial  cryptography  developments  since 
publication  of  the  1994  report.  This  is  not  a  com¬ 
prehensive  survey  of  commercial  information-se¬ 
curity  products  and  proposals.  Mention  of 
individual  companies  or  products  is  for  illustra¬ 
tive  purposes  and/or  identification  only,  and 


3  See  Elizabeth  Sikorovsky,  “Energy  Group  Uncovers  Hole  in  Web  Software,”  Federal  Computer  Week,  Feb.  20, 1 995,  pp.  3-4;  and  Richard 
W.  Wiggins,  “Business  Browser,”  Internet  World ,  February  1995,  pp.  52-55. 

4  See,  e.g.,  Jared  Sandberg,  “GE  Says  Computers  Linked  to  Internet  Were  Infiltrated,”  The  Wall  Street  Journal,  Nov.  28, 1994;  or  Bob  Bre- 
win  and  Elizabeth  Sikorovsky,  “DISA  Stings  Uncover  Computer  Security  Flaws,”  Federal  Computer  Week ,  Feb.  6,  1995,  pp.  1-45.  See  also 
Vanessa  Jo  Grimm,  “In  War  on  System  Intruders,  DISA  Calls  in  Big  Guns,”  Government  Computer  News ,  Feb.  6,  1995,  pp.  41-42. 

5  See  Neil  Munro,  “New  Info- War  Doctrine  Poses  Risks,  Gains,”  Washington  Technology,  Dec.  22,  1994,  pp.  1, 12;  and  “How  Private  Is 
Your  Data?”  Washington  Technology ,  Feb.  9,  1995,  pp.  14,  16. 

6  Firewalls  are  network  barriers  that  filter  network  traffic,  for  example,  denying  incoming  telnet  or  ftp  connections  except  to  designated 
directories,  from  designated  network  domains  or  IP  addresses.  Active  intrusion-detection  systems  look  for  anomalous  or  abnormal  processes 
(like  extended  log-on  attempts  as  an  intruder  tries  to  “guess”  valid  passwords,  attempts  to  copy  password  files  or  system  programs),  curtail 
them,  and  alert  security  officers.  See,  e.g.,  Stallings,  op.  cit.,  footnote  2;  Warwick  Ford,  Computer  Communications  Security  (Englewood  Cliffs, 
NJ:  Prentice  Hall,  1994);  and  Jeffrey  I.  Schiller,  “Secure  Distributed  Computing,”  Scientific  American ,  November  1994,  pp.  72-76. 

7  Recent  government  efforts  to  promote  use  of  security  technologies  include  several  cataloging  and  technology  transfer  efforts  undertaken 
by  the  Office  of  Management  and  Budget,  National  Institute  of  Standards  and  Technology,  and  the  Defense  Department.  See  Neil  Munro,  “Feds 
May  Share  Security  Tech,”  Washington  Technology,  Nov.  10,  1994,  pp.  1,  22. 
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should  not  be  interpreted  as  endorsement  of  these 
products  or  approaches. 

I  Executive  Branch  Developments8 

In  mid- 1994,  the  executive  branch  indicated  an 
openness  toward  exploring  alternative  forms  of 
key-escrow  encryption  (i.e.,  techniques  not  im¬ 
plementing  the  Skipjack  algorithm  specified  in 
the  Escrowed  Encryption  Standard  (EES))  for  use 
in  computer  and  video  networks.9  However,  there 
has  been  no  formal  commitment  to  eventually 
adopting  any  alternative  to  Skipjack  in  a  federal 
escrowed-encryption  standard  for  computer 
data.10  Moreover,  there  has  been  no  commitment 
to  consider  alternatives  to  the  EES  for  telephony. 

The  question  of  whether  or  when  there  will  be 
key-escrow  encryption  federal  information  proc¬ 
essing  standards  (FIPS)  for  unclassified  data  com¬ 
munications  and/or  file  encryption  is  still  open. 
There  is  at  present  no  FIPS  specifying  use  of  Skip¬ 
jack  for  these  applications.  (The  EES  specifies  an 
implementation  of  Skipjack  as  a  standard  for  use 
in  telephone,  not  computer,  communications.) 
However,  the  Capstone  chip  and  FORTEZZA 
card  implementation  of  the  Skipjack  algorithm  is 
being  used  by  the  Defense  Department  in  the  De¬ 
fense  Message  System. 

Furthermore,  there  has  been  no  backing  away 
from  the  underlying  Clinton  Administration  com¬ 
mitment  to  “escrowing”  encryption  keys.  With  es¬ 


crowing,  there  is  mandatory  key  deposit.  In  the 
future,  there  may  be  some  choice  of  “escrow  agen¬ 
cies”  or  registries,  but  at  present,  EES  and  Cap¬ 
stone-chip  keys  are  being  escrowed  within  the 
Commerce  and  Treasury  Departments.  The  notion 
of  optional  deposit  of  keys  with  registries,  which 
OTA  referred  to  as  “trusteeship”  in  the  1994  report 
(to  distinguish  it  from  the  Clinton  Administra¬ 
tion’s  concept  of  key  escrowing  being  required  as 
an  integral  part  of  escrowed-encryption  systems), 
is  not  being  considered. 1 1 

Implementation  of  key  escrowing  or  trusteeship 
for  large  databases  (i.e.,  encryption  for  file  stor¬ 
age,  as  opposed  to  communications)  has  not  been 
addressed  by  the  government.  However,  commer¬ 
cial  key  depositories  or  data-recovery  centers  are 
being  proposed  by  several  companies  (see  next 
section  on  private  sector  developments).  At  pres¬ 
ent,  there  is  no  FIPS  for  secure  key  exchange  (e.g., 
for  use  with  the  Data  Encryption  Standard  (DES). 

Turning  from  encryption  to  digital  signatures, 
acceptance  and  use  of  the  new  FIPS  for  digital  sig¬ 
natures  are  progressing,  but  slowly.  As  the  1994 
report  detailed  in  its  description  of  the  evolution 
of  the  Digital  Signature  Standard  (DSS),  patent 
problems  complicated  the  development  and  pro¬ 
mulgation  of  the  standard.12  Patent-infringement 
uncertainties  remain  for  the  DSS,  despite  the  gov¬ 
ernment’s  insistence  that  the  DSS  algorithm  does 
not  infringe  any  valid  patents  and  its  offer  to  in- 


8  See  also  OTA,  op.  cit.,  footnote  1,  pp.  171-182, 

9  For  background,  see  appendix  E  of  this  background  paper  and  OTA,  op,  cit.,  footnote  1 ,  pp.  15-16  and  171-174.  The  Escrowed  Encryption 
Standard  is  described  in  box  2-3  of  this  background  paper. 

10  See  box  2-3.  The  Capstone  chip  refers  to  a  hardware  implementation  of  the  EES’s  Skipjack  algorithm,  but  for  data  communications. 
FORTEZZA  (formerly  TESSERA)  is  a  PCMCIA  card  implementing  Skipjack  for  data  encryption,  as  well  as  the  Digital  Signature  Standard 
(DSS — see  box  2-2)  and  key-exchange  functions. 

11  See  OTA,  op.  cit.,  footnote  1,  p.  171. 

12  See  OTA,  op.  cit.,  footnote  1,  appendix  C,  especially  pp.  220-2 1 .  For  a  more  recent  account  of  the  various  lawsuits  and  countersuits  among 
patentholders,  licensers,  and  licensees,  see  Simson  Garfinkle,  PGP:  Pretty  Good  Privacy  (Sebastopol,  C  A:  O’Reilly  and  Assoc.,  1 995),  esp.  ch. 
6. 
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demnify  vendors  that  develop  certificate  authori¬ 
ties  for  a  public-key  infrastructure.13 

Plans  to  implement  the  DSS  throughout  govern¬ 
ment  are  complicated  by  the  relatively  broad  pri¬ 
vate-sector  use  of  a  commercial  alternative,  the 
RSA  signature  system,  and  some  agencies’  desire 
to  use  the  RSA  system  instead  of,  or  alongside,  the 
Digital  Signature  Standard  (DSS).  For  example, 
some  federal  agencies  (e.g.,  the  Central  Intelli¬ 
gence  Agency)  have  already  purchased  and  imple¬ 
mented  commercial  software  packages  containing 
RSA-based  security  features.14  Moreover,  many 
agencies  and  their  contractors  are  interested  in 
software-based  signature  systems,  rather  than 
hardware-based  implementations.  For  example, 
the  Westinghouse  Savannah  River  Company, 
which  is  the  management  and  operating  contrac¬ 
tor  for  the  DOE  at  the  Savannah  River  Site,  is 
seeking  a  business  partner  under  a  cooperative  re¬ 
search  and  development  agreement  (CRADA)  ar¬ 
rangement  for  collaborative  development  of 
software  involving  application  and  integration  of 
the  DSS  into  business-applications  software 
packages.  The  goal  of  the  CRADA  project  is  to 
produce  a  software  product  or  module  that  can  be 
used  to  replace  paper-based  approval  signatures 
with  digital  signatures.  These  digital  signatures 
would  be  used,  for  example,  for  time  and  atten¬ 
dance  reporting,  travel  expense  reporting,  and 
other  forms  management  and  routing  in  local  area 
networks.15 


Cost,  as  well  as  interoperability  with  the  private 
sector,  is  an  issue.  The  DSS  can  be  implemented  in 
hardware,  software,  or  firmware,  but  the  National 
Security  Agency’s  (NSA’s)  preferred  imple¬ 
mentation  is  in  the  FORTEZZA  card,  along  with 
the  EES  algorithm.  The  FORTEZZA  card  (for¬ 
merly  called  the  TESSERA  card)  is  a  Personal 
Computer  Memory  Card  Industry  Association 
(PCMCIA)  card.16  The  FORTEZZA  card  is  used 
for  data  communications;  it  implements  the  Skip¬ 
jack  algorithm,  as  well  as  key-exchange  and  digi¬ 
tal-signature  functions.  FORTEZZA  applications 
include  the  Defense  Department’s  Defense  Mes¬ 
sage  System.  Per-workstation  costs  are  signifi¬ 
cantly  higher  for  the  FORTEZZA  card  than  for  a 
software-based  signature  implementation  alone. 
To  use  FORTEZZA,  agencies  must  have — or  up¬ 
grade  to — computers  with  PCMCIA  card  slots,  or 
must  buy  PCMCIA  readers  (about  $125  each). 

According  to  NSA,  current  full  costs  for  FOR¬ 
TEZZA  cards  are  about  $150  each  in  relatively 
small  initial  production  lots;  of  this  cost,  about 
$98  is  for  the  Capstone  chip.  About  3,000  FOR¬ 
TEZZA  cards  had  been  produced  as  of  April  1995 
and  another  33,000  were  on  contract.  NSA  hopes 
to  award  a  large-scale  production  contract  in  fall 
1995  for  200,000  to  400,000  units.  In  these  quan¬ 
tities,  according  to  NSA,  unit  costs  should  be  be¬ 
low  the  $100  per  unit  target  established  for  the 
program.17  Thus,  the  FORTEZZA  production 


13  F.  Lynn  McNulty  et  al.,  NIST,  “Digital  Signature  Standard  Update,”  Oct.  11, 1994.  The  government  offered  to  include  an  “authorization 
and  consent”  clause  under  which  the  government  would  assume  liability  for  any  patent  infringement  resulting  from  performance  of  a  contract, 
including  use  of  the  DSS  algorithm  or  public-key  certificates  by  private  parties  when  communicating  with  the  government.  See  also  OTA,  op. 
cit.,  footnote  1,  ch.  3. 

14  See  Brad  Bass,  “Federal  Encryption  Policy  Shifts  Direction  ,”  Federal  Computer  Week,  Feb.  20,  1995,  pp.  28-29.  Lotus  Notes  [TM],  a 
“groupware”  package  that  has  RSA  public-key  and  access-control  security  features,  is  reportedly  used  to  handle  over  85  percent  of  the  Central 
Intelligence  Agency’s  (CIA’s)  email  traffic.  (Adam  Gaff  in,  “CIA  Espies  Value  in  Turning  to  Lotus  Notes,1 "Network  World ,  Mar.  13, 1995,  p.  43.) 

Commerce  Business  Daily ,  Apr.  5,  1995. 

16  PCMCIA  cards  are  slightly  larger  than  a  credit  card,  with  a  connector  on  one  end  that  plugs  directly  into  a  standard  slot  in  a  computer  (or 
reader).  They  contain  microprocessor  chips;  for  example,  the  FORTEZZA  card  contains  a  Capstone  chip. 

17  Bob  Drake,  Legislative  Affairs  Office,  NSA,  personal  communication,  Apr.  7, 1995.  To  make  the  apparent  price  of  FORTEZZA  cards 
more  attractive  to  Defense  Department  customers  in  the  short  term,  NSA  is  splitting  the  cost  of  the  Capstone  chip  with  them,  so  agencies  can 
acquire  the  early  versions  of  FORTEZZA  for  $98  apiece  (ibid.). 
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contract  would  be  on  the  order  of  $20  million  to 
$40  million. 

The  National  Institute  of  Standards  and 
Technology  (NIST)  is  working  on  what  is  in¬ 
tended  to  become  a  market-driven  validation  sys¬ 
tem  for  vendors’  DSS  products.  This  is  being  done 
within  the  framework  of  overall  requirements  de¬ 
veloped  for  FIPS  140-1,  “Security  Requirements 
for  Cryptographic  Modules”  (January  11,  1994). 
NIST  is  also  developing  a  draft  FIPS  for  “Crypto¬ 
graphic  Service  Calls”  that  would  use  relatively 
high-level  application  program  interfaces  (e.g., 
“sign”  or  “verify”)  to  call  on  any  of  a  variety  of 
cryptographic  modules.  The  intention  is  to  allow 
flexibility  of  implementation  in  what  NIST  recog¬ 
nizes  is  a  “hybrid  world.”  Unfortunately,  this 
work  appears  to  have  been  slowed  due  to  the  tradi¬ 
tional  scarcity  of  funds  for  such  core  security  pro¬ 
grams  at  NIST  (see  chapter  2  and  the  1994  OTA 
report,  pp.  20  and  164). 

Due  to  lack  of  procurement  funds  and  to  avoid 
duplicating  other  agencies’  operational  efforts, 
NIST  did  not  issue  a  solicitation  for  public-key 
certificate  services.  The  U.S.  Postal  Service  and 
the  General  Services  Administration  have  at  pres¬ 
ent  taken  the  lead  on  a  government  public-key  in¬ 
frastructure.18  The  1996  Clinton  Administration 
budget  proposals  reportedly  do  not  specify  funds 
for  NIST  work  related  to  the  DSS,  or  the  EES.19 
However,  according  to  the  draft  charter  of  the 
Government  Information  Technology  Services 
Public-Key  Infrastructure  Federal  Steering  Com¬ 
mittee,  NIST  will  chair  and  provide  administra¬ 
tive  support  for  the  Public-Key  Infrastructure 
(PKI)  Federal  Steering  Commmittee  that  is  being 


formed  to  provide  guidance  and  assistance  in  de¬ 
veloping  an  interoperable,  secure  public-key  in¬ 
frastructure  to  support  electronic  commerce, 
electronic  mail,  and  other  applications. 

The  Advanced  Research  Projects  Agency 
(ARPA),  the  Defense  Information  Systems 
Agency,  and  NSA  have  agreed  to  establish  an  In¬ 
formation  Systems  Security  Research  Joint 
Technology  Office  (JTO)  to  coordinate  research 
programs  and  long-range  strategic  planning  for 
information  systems  security  research  and  to  ex¬ 
pedite  delivery  of  security  technologies  to  DISA. 
Part  of  the  functions  of  JTO  will  be  to: 

■  Encourage  the  U.S.  industrial  base  to  develop 
commercial  products  with  built-in  security  to 
be  used  in  Defense  Department  systems.  De¬ 
velop  alliances  with  industry  to  raise  the  lev¬ 
el  of  security  in  all  U.S.  systems.  Bring 
together  private  sector  leaders  in  information 
security  to  advise  JTO  and  build  consensus 
for  the  resulting  program. 

■  Identify  areas  for  which  standards  need  to  be 
developed  for  information  systems  security. 

■  Facilitate  the  availability  and  use  of  NSA- 
certified  cryptography  within  information 
systems  security  research  programs.20 

According  to  the  Memorandum  of  Agreement  es¬ 
tablishing  JTO,  its  work  is  intended  to  improve 
DISA’s  ability  to  safeguard  the  confidentiality,  in¬ 
tegrity,  authenticity,  and  availability  of  data  in  De¬ 
fense  Department  information  systems,  provide  a 
“robust  first  line  of  defense”  for  defensive  in¬ 
formation  warfare,  and  permit  electronic  com¬ 
merce  between  the  Defense  and  its  contractors. 
(See  discussion  of  the  Defense  Department’s  “In¬ 
formation  Warfare”  activities  later  in  this  chapter.) 


18  F.  Lynn  McNulty  et  al.f  NIST,  personal  communication,  Feb.  24,  1995. 

19  Kevin  Power,  “Fate  of  Federal  DSS  in  Doubt,”  Government  Computer  News,  Mar.  6,  1995.  The  President’s  budget  does  provide  $100 
million  to  implement  the  digital  wiretap  legislation  enacted  at  the  close  of  the  103d  Congress.  See  U.S.  Congress,  Office  of  Technology  Assess¬ 
ment,  Electronic  Surveillance  in  Advanced  Telecommunications  Networks ,  Background  Paper,  forthcoming,  spring  1995. 

20  “Memorandum  of  Agreement  Between  the  Advanced  Research  Projects  Agency,  the  Defense  Information  Systems  Agency,  and  the  Na¬ 
tional  Security  Agency  Concerning  the  Information  Systems  Security  Research  Joint  Technology  Office,”  Mar.  3, 1995  (effective  Apr.  2, 1995). 
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I  Private  Sector  Developments 

At  the  end  of  January  1995,  AT&T  Corp.  and 
VLSI  Technology,  Inc.,  announced  plans  to  devel¬ 
op  an  encryption  microchip  that  would  rival  the 
Clipper  and  Capstone  chips.  The  AT&T/ VLSI 
chip  will  have  the  stronger,  triple-DES  imple¬ 
mentation  of  the  Data  Encryption  Standard  algo¬ 
rithm.21  It  is  intended  for  use  in  a  variety  of 
consumer  devices,  including  cellular  telephones, 
television  decoder  boxes  for  video-on-demand 
services,  and  personal  computers.22  The  AT&T/ 
VLSI  chips  do  not  include  key  escrowing.  Under 
current  export  regulations,  they  would  be  subject 
to  State  Department  export  controls. 

Industry  observers  consider  this  development 
especially  significant  as  an  indicator  of  the  lack  of 
market  support  for  Clipper  and  Capstone  chips  be¬ 
cause  AT&T  manufactures  a  commercial  product 
using  Clipper  chips  (the  AT&T  Surity  Telephone 
Device)  and  VLSI  is  the  NSA  contractor  making 
the  chips  that  Mykotronx  programs  (e.g.,  with  the 
Skipjack  algorithm  and  keys)  to  become  Clipper 
and  Capstone  chips. 

The  international  banking  and  financial  commu¬ 
nities  have  long  used  encryption  and  authentica¬ 
tion  methods  based  on  the  DES.  These  have  a 
large  installed  base  of  DES  technology;  a  transi¬ 
tion  to  an  incompatible  (non-DES -based)  new 
technology  would  be  lengthy.  The  Accredited 
Standards  Committee  (ASC  X9),  which  sets  data 
security  standards  for  the  U.S.  banking  and  finan¬ 


cial  services  industries,  has  announced  that  it  will 
develop  new  encryption  standards  based  on  triple 
DES.  ASC  X9  will  designate  a  subcommittee  to 
develop  technical  standards  for  triple-DES  ap¬ 
plications.23 

RSA  Data  Security,  Inc.,  recently  announced 
another  symmetric  encryption  algorithm,  called 
RC5.24  According  to  the  company,  RC5  is  faster 
than  the  DES  algorithm,  is  suitable  for  hardware 
or  software  implementation,  and  has  a  range  of 
user-selected  security  levels.  Users  can  select  key 
lengths  ranging  up  to  2,040  bits,  depending  on  the 
levels  of  security  and  speed  needed.  The  RSA  dig¬ 
ital  signature  system  (see  box  2-2),  from  the  same 
company,  is  a  leading  commercial  rival  to  the  Dig¬ 
ital  Signature  Standard.  RSA-based  technology  is 
also  part  of  a  new,  proposed  industry  standard  for 
protecting  business  transactions  on  the  Internet.25 

Another  private  sector  standards  group,  the 
IEEE  P1363  working  group  on  public-key  cryp¬ 
tography,  is  developing  a  voluntary  standard  for 
“RSA,  Diffie-Hellman,  and  Related  Public-Key 
Cryptography”  (see  figure  2-5).  The  group  held  a 
public  meeting  in  Oakland,  California,  on  May 
10, 1995,  to  review  a  draft  standard.26 

Several  companies  and  individuals  have  pro¬ 
posed  alternative  approaches  to  key-escrow 
encryption.27  According  to  a  “taxonomy”  by  Dor¬ 
othy  Denning  and  Dennis  Branstad,  there  are 
some  20  different  alternatives,  including: 


21  In  “triple  DES,”  the  DES  algorithm  is  used  sequentially  with  three  different  keys,  to  encrypt,  decrypt,  then  re-encrypt.  Triple  encryption 
with  the  DES  offers  more  security  than  having  a  secret  key  that  is  twice  as  long  as  the  56-bit  key  specified  in  the  FIPS.  There  is,  however,  no  FIPS 
specifying  triple  DES. 

22  Jared  Sandberg  and  Don  Clark,  “AT&T,  VLSI  Technology  To  Develop  Microchips  That  Offer  Data  Security,”  The  Wall  Street  Journal 
Jan.  31,  1995;  see  also  Brad  Bass,  op.  cit.,  footnote  19. 

23  CIPHER  (Newsletter  of  the  IEEE  Computer  Society’s  TC  on  Security  and  Privacy),  Electronic  Issue  No.  4,  Carl  Landwehr  (ed),  Mar.  10, 
1995,  available  from  (http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/cipher-archive.html). 

24  Ronald  L.  Rivest,  “The  RC5  Encryption  Algorithm,”  Dr.  Dobb’s  Journal ,  January  1995,  pp.  146,  148. 

25  Peter  H.  Lewis,  “Accord  Is  Reached  on  a  Common  Security  System  for  the  Internet,”  The  New  York  Times ,  Apr.  11,  1995,  p.  D5.  The 
proposed  standard  will  be  used  to  safeguard  World  Wide  Web  services. 

26  Ibid.  Draft  sections  are  available  via  anonymous  ftp  to  rsa.com  in  the  “pub/p  1363”  directory.  The  working  group’s  electronic  mailing  list 
is  <pl363@rsa.com>;  to  join,  send  e-mail  to  <p  1363 -request @rsa.com>. 

27  See  Elizabeth  Corcoran,  “Three  Ways  To  Catch  a  Code,”  Washington  Post ,  Mar.  16,  1995,  pp.  Bl,  B12.  The  article  also  discusses  the 
Hewlett-Packard’s  proposed  “national  flag  card”  approach  to  government- approved  encryption. 
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■  AT&T  CryptoBackup, 

■  Bankers  Trust  International  Corporate  Key 
Escrow, 

■  Bell  Atlantic  Key  Escrow, 

■  Fortress  KISS, 

■  Micali  Fair  Cryptosystems, 

-  TECSEC  VEIL, 

■  TIS  Commercial  Software  Key  Escrow 
System, 

■  and 

■  TIS  Software  Key  Escrow  System.28 

Variously,  these  use  public  (i.e.,  published,  un¬ 
classified)  encryption  algorithms,  thus  potentially 
allowing  implementation  in  software  as  well  as 
hardware.  They  use  commercial  or  private  key-es¬ 
crow  systems,  with  data  recovery  services  that  can 
be  made  available  to  individuals  and  organiza¬ 
tions,  as  well  as  to  law  enforcement  (with  proper 
authorization).  A  brief  description  of  two  of  the 
commercial  approaches  follows,  based  on  in¬ 
formation  provided  by  Trusted  Information  Sys¬ 
tems  (TIS)  and  Bankers  Trust.  The  Bankers  Trust 
system  is  hardware  based;  the  TIS  system  is  soft¬ 
ware-based. 

Bankers  Trust  has  proposed  its  system  to  the 
U.S.  government  and  business  community.  Ac¬ 
cording  to  Bankers  Trust,  its  international  private 
key-escrow  system  ensures  privacy  and  security, 
while  preserving  law  enforcement  and  national  se¬ 
curity  capabilities.  Bankers  Trust  believes  there  is 
a  need  for  escrowed  keys  in  business  applications, 
so  that  encrypted  information  can  be  recovered 
when  a  key  has  been  lost  or  is  otherwise  unavail¬ 
able.  The  Bankers  Trust  system  supports  different 
encryption  methods,  thus  accommodating  differ¬ 
ent  national  policies  (e.g.,  regarding  export,  im¬ 
port,  or  use  controls).  The  Bankers  Trust  system 


uses  a  hardware  device  to  encrypt  information 
stored  in  and  transmitted  through  global  infor¬ 
mation  infrastructures,  including  voice,  fax, 
store-and-forward  messaging,  and  data-storage- 
and-retrieval  systems.  Bankers  Trust  believes  that 
the  requirement  of  a  device  will  be  consistent  with 
the  rapidly  emerging  use  of  smart  cards  for  net¬ 
work  financial  transactions,  together  with  the 
need  to  secure  the  global  information  infrastruc¬ 
ture  against  potential  abuse.29 

Under  Bankers  Trust’s  system,  the  owner  of  the 
encryption  device  selects  an  encryption  algorithm 
and  escrows  the  key  or  fragments  of  the  key  with 
one  or  more  trusted  entities  (escrow  agents). 
These  could  be  a  commercial  company.  The  sys¬ 
tem  allows  owners  to  freely  change  algorithms, 
keys,  and  agents  at  any  time;  owners  might  make 
these  changes  as  part  of  a  standard  security  policy 
or  as  an  added  security  measure  after  any  sus¬ 
pected  problem.  Bankers  Trust’s  system  enables 
owners  to  access  their  key(s)  to  decrypt  encrypted 
information  when  necessary.  It  also  permits  law 
enforcement,  with  proper  legal  authorization,  to 
obtain  keys  to  decrypt  information.  Additionally, 
it  contains  extensive  audit  and  other  procedures  to 
ensure  the  integrity  of  the  system.30 

The  government  is  looking  at  various  alternative 
approaches  to  key-escrow  encryption.  At  this 
writing,  the  commercial  escrowing  alternative 
proposed  by  Trusted  Information  Systems,  Inc.,  is 
undergoing  internal  government  review  to  deter¬ 
mine  whether  such  an  approach  may  be  feasible  to 
meet  national  security  and  law  enforcement  objec¬ 
tives.31  The  TIS  approach  is  software  rather  than 
hardware-based.32  Like  the  Bankers  Trust  system, 
but  in  contrast  to  the  EES/Capstone  approach  to 
escrowing,  it  would  also  permit  the  rightful  “key 


28  See  Dorothy  E.  Denning  and  Dennis  Branstad,  “A  Taxonomy  for  Key  Escrow  Encryption,”  forthcoming,  obtained  from  the  author  (den- 
ning  @cs. georgetown.edu). 

29  Nanette  DiTosto,  Bankers  Trust,  personal  communication,  Apr.  10,  1995. 

30  Ibid. 

31  F.  Lynn  McNulty,  Associate  Director  for  Computer  Security,  NIST,  personal  communications,  Feb.  24,  1995  and  Mar.  21,  1995. 

32  Stephen T.  Walker,  et  al,  “Commercial  Key  Escrow:  Something  for  Everyone,  Now  and  for  the  Future,”  Jan.  3, 1995,  Trusted  Information 
Systems,  Inc.,  TIS  Report  No.  541. 
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owners” — not  just  law  enforcement  agencies — to 
recover  the  contents  of  encrypted  messages  or 
files,  if  the  keys  became  unavailable  due  to  acci¬ 
dent,  malfeasance,  error,  or  so  forth. 

In  the  TIS  scheme,  a  user  would  register  his  or 
her  escrowed-encryption  computer  program  with 
a  commercial,  government,  or  corporate  data  re¬ 
covery  center.  The  interactive  registration  process 
would  provide  the  user’s  computer  program  with 
information  to  be  used  in  creating  the  “data  recov¬ 
ery  field”  (analogous  to  the  LEAF  in  the  EES 
method — see  box  2-3)  that  would  be  appended  to 
all  encrypted  communications  (or  files).  Any  en¬ 
cryption  algorithm  could  be  used  but  the  software 
implementation  cannot  protect  the  “secrecy”  of  a 
classified  algorithm.  According  to  TIS,  its  pro¬ 
posal  relies  on  “binding”  a  software  key-escrow 
system  to  the  chosen  encryption  algorithm.  Imple¬ 
menting  this  type  of  software  “binding”  is  diffi¬ 
cult,  but  if  done  properly,  it  would  prevent 
someone  from  separating  the  computer  program’s 
encryption  functions  from  the  key-escrowing 
functions  and  would  prevent  use  of  the  program 
for  encryption  using  nonescrowed  keys.  The 
“binding”  features  of  the  TIS  proposal  are  in¬ 
tended  to  prevent  use  of  the  encryption  function  if 
key  escrowing  is  disabled,  or  “spoofing”  the  sys¬ 
tem  by  creating  spurious  data  recovery  fields.33 

UPDATE  ON  BUSINESS  PERSPECTIVES 

Representatives  of  major  U.S.  computer  and  soft¬ 
ware  companies  have  reaffirmed  the  importance 
of  security  and  privacy  protections  in  the  develop¬ 
ing  global  information  infrastructure  (GII).  Ac¬ 
cording  to  the  Computer  Systems  Policy  Project 
(CSPP): 

The  GII  will  not  flourish  without  effective  se¬ 
curity  mechanisms  to  protect  commercial  trans¬ 
actions.  Consumers  and  providers  of  products 
and  services,  particularly  those  involving  health 


care  and  international  commerce,  will  not  use 
GII  applications  unless  they  are  confident  that 
electronic  communications  and  transactions 
will  be  confidential,  that  the  origin  of  messages 
can  be  verified,  that  personal  privacy  can  be  pro¬ 
tected,  and  that  security  mechanisms  will  not 
impede  the  transnational  flow  of  electronic 
data.34 

But  there  are  strong  and  serious  business  concerns 
that  government  interests,  especially  in  the  stan¬ 
dards  arena,  could  stifle  commercial  development 
and  use  of  networks  in  the  international  arena: 

Governments  have  a  critical  interest  in  com¬ 
mercial  security  mechanisms  that  are  consistent 
with  their  own  national  security  needs.  As  a  re¬ 
sult,  they  must  participate  in  private  sector  ef¬ 
forts  to  develop  and  adopt  security  standards. 
However,  government  needs  should  not  be  used 
as  reasons  to  replace  or  overwhelm  the  private 
sector  standards  processes. 

To  meet  the  security  goals  for  the  GII  (as  well 
as  privacy  goals  supported  by  security  solutions), 
the  CSPP  recommended  that: 

■  All  participating  countries  must  adopt  stan¬ 
dards  to  support  mechanisms  that  are  accept¬ 
able  to  the  private  sector  and  suitable  to 
commercial  transactions.  These  standards 
must  also  ensure  privacy  and  authentication. 
This  may  require  nations  to  adopt  commer¬ 
cial  security  solutions  that  are  different  and 
separate  from  solutions  for  national  security 
and  diplomatic  purposes. 

■  The  U.S.  government  must  cooperate  with  in¬ 
dustry  to  resolve  U.S.  policy  concerns  that 
have  blocked  acceptance  of  international  en¬ 
cryption  mechanisms  necessary  for  commer¬ 
cial  transactions. 

■  The  private  sector  and  government  should 
convene  a  joint  international  conference  to 
address  the  need  for  security  mechanisms  to 
support  commercial  applications  and  to  de- 


33  Steve  Lipner,  Trusted  Information  Systems,  Inc.,  personal  communication,  Jan.  9,  1995.  According  to  Lipner,  the  National  Security 
Agency  introduced  the  term  binding  to  the  lexicon,  to  refer  to  this  feature. 

34  Computer  Systems  Policy  Project,  Perspectives  on  the  Global  Information  Infrastructure ,  February  1995,  p.  9. 
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velop  a  strategy  for  implementing  acceptable 
security  solutions.35 

In  June  1994,  the  Association  for  Computing 
Machinery  (ACM)  issued  a  report  on  the  policy  is¬ 
sues  raised  by  introduction  of  the  EES.  The  ACM 
report,  prepared  by  a  panel  drawn  from  govern¬ 
ment,  the  computer  industry,  and  the  legal  and 
academic  communities,  discussed  the  history  and 
technology  of  cryptography  and  the  value  and  im¬ 
portance  of  privacy,  concluding  with  identifica¬ 
tion  of  key  questions  that  need  to  be  considered  in 
reaching  conclusions  regarding: 

What  cryptography  policy  best  accommo¬ 
dates  our  national  needs  for  secure  communica¬ 
tions  and  privacy,  industry  success,  effective 
law  enforcement,  and  national  security?36 

The  U.S.  Public  Policy  Committee  of  the  ACM 
(USACM)  issued  a  companion  set  of  recommen¬ 
dations,  focusing  on  the  need  for: 

■  open  forums  for  cryptography  policy  devel¬ 
opment,  in  which  government,  industry,  and 
the  public  could  participate; 

■  encryption  standards  that  do  not  place  U.S. 
manufacturers  at  a  disadvantage  in  the  global 
marketplace  and  do  not  adversely  affect  tech¬ 
nological  development  within  the  United 
States; 

■  changes  in  FIPS  development,  such  as  plac¬ 
ing  the  process  under  the  Administrative  Pro¬ 
cedures  Act; 

■  withdrawal  of  the  Clipper  chip  proposal  by 
the  Clinton  Administration  and  the  begin¬ 
ning  of  an  open  and  public  review  of  encryp¬ 
tion  policy;  and 

■  development  of  technologies  and  institution¬ 
al  practices  that  will  provide  real  privacy  for 
future  users  of  the  National  Information  In¬ 
frastructure  (Nil).37 


Also  in  1994,  the  International  Chamber  of 
Commerce  (ICC)  issued  its  “ICC  Position  Paper 
on  International  Encryption  Policy.”  ICC  noted 
the  growing  importance  of  cryptography  in  secur¬ 
ing  business  information  and  transactions  on  an 
international  basis  and,  therefore,  the  significance 
of  restrictions  and  controls  on  encryption  methods 
as  “artificial  obstacles”  to  trade.  ICC  urged  gov¬ 
ernments  “not  to  adopt  a  restrictive  approach 
which  would  place  a  particularly  onerous  burden 
on  business  and  society  as  a  whole.”38  ICC’s  posi¬ 
tion  paper  called  on  governments  to:  1)  remove 
unnecessary  export  and  import  controls,  usage  re¬ 
strictions,  restrictive  licensing  arrangements  and 
the  like  on  encryption  methods  used  in  commer¬ 
cial  applications;  2)  enable  network  interoperabil¬ 
ity  by  encouraging  global  standardization;  3) 
maximize  users’  freedom  of  choice;  and  4)  work 
together  with  industry  to  resolve  barriers  by  joint¬ 
ly  developing  a  comprehensive  international 
policy  on  encryption.  ICC  recommended  that 
global  encryption  policy  be  based  on  broad  prin¬ 
ciples: 

■  Different  encryption  methods  will  be  needed 
to  fulfill  a  variety  of  user  needs.  Users  should 
be  free  to  use  and  implement  the  already  ex¬ 
isting  framework  of  generally  available  and 
generally  accepted  encryption  methods  and 
to  choose  keys  and  key  management  without 
restrictions.  Cryptographic  algorithms  and 
key-management  schemes  must  be  open  to 
public  scrutiny  for  the  commercial  sector  to 
gain  the  necessary  level  of  confidence  in 
them. 

■  Commercial  users,  vendors,  and  govern¬ 
ments  should  work  together  in  an  open  in¬ 
ternational  forum  in  preparing  and  approving 
global  standards. 


35  Ibid.,  pp.  9-10. 

36  Susan  Landau  et  al.,  “Codes,  Keys,  and  Conflicts:  Issues  in  U.S.  Crypto  Policy,”  Association  for  Computing  Machinery,  Inc.,  June  1994. 

37  USACM,  June  1994. 

38  International  Chamber  of  Commerce,  ICC  Position  Paper  on  International  Encryption  Policy  (Paris:  ICC,  1994),  pp.  2,3.  See  also  United 
States  Council  for  International  Business,  “Private  Sector  Leadership:  Policy  Foundations  for  a  National  Information  Infrastructure,”  New 
York,  NY,  July  1994,  p  5. 
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■  Both  hardware  and  software  implementations 
of  encryption  methods  should  be  allowed. 
Vendors  and  users  should  be  free  to  make 
technical  and  economic  choices  about  modes 
of  implementation  and  operation. 

■  Owners,  providers,  and  users  of  encryption 
methods  should  agree  on  the  responsibility, 
accountability,  and  liability  for  such 
methods. 

■  With  the  exception  of  encryption  methods 
specifically  developed  for  military  or  diplo¬ 
matic  uses,  encryption  methods  should  not  be 
subject  to  export  or  import  controls,  usage  re¬ 
strictions,  restrictive  licensing  arrangements, 
or  other  restrictions.39 

The  United  States  Council  for  International 
Business  (USCIB)  subsequently  issued  position 
papers  on  “Business  Requirements  for  Encryp¬ 
tion”40  and  “Liability  Issues  and  the  U.S.  Admin¬ 
istration’s  Encryption  Initiatives.”41  The  USCIB 
favored  breaking  down  the  “artificial  barriers”  to 
U.S.  companies’  competitiveness  and  ability  to 
implement  powerful  security  imposed  by  overly 
restrictive  export  controls.  The  Council  called  for 
international  agreement  on  realistic  encryption  re¬ 
quirements,  including  free  choice  of  encryption 
algorithms  and  key  management  methods,  public 
scrutiny  of  proposed  standard  algorithms,  free  ex¬ 
port/import  of  accepted  standards,  flexibility  in 
implementation  (hardware  or  software),  and  li¬ 
ability  requirements  for  escrow  agents  if  escrow¬ 
ing  is  used: 

Business  recommends  the  removal  of  un¬ 
founded  export  controls  on  commercial  encryp¬ 
tion.  In  the  absence  of  relief  from  export 
controls,  business  recommends  that  the  follow¬ 
ing  steps  be  undertaken  in  order  to  achieve  an 
encryption  policy  that  is  internationally  accept¬ 
able: 


(a)  the  Administration  endorse  the  require¬ 
ments  outlined  in  this  paper 

(b)  the  Administration  enter  into  bilateral  and 
multilateral  discussions  with  other  nations 
to  achieve  the  widespread  adoption  of  these 
requirements. 

If  key  escrowing  is  to  be  used,  the  USCIB  pro¬ 
posed  that: 

■  a  government  not  be  the  sole  holder  of  the  en¬ 
tire  key  except  at  the  discretion  of  the  user; 

■  the  key  escrow  agent  make  keys  available  to 
lawfully  authorized  entities  when  presented 
with  proper,  written  legal  authorizations  (in¬ 
cluding  international  cooperation  when  the 
key  is  requested  by  a  foreign  government); 

■  the  process  for  obtaining  and  using  keys  for 
wiretapping  purposes  must  be  auditable; 

■  keys  obtained  from  escrowing  agents  by  law 
enforcement  must  be  used  only  for  a  speci¬ 
fied,  limited  time  frame;  and 

■  the  owner  of  the  key  must  (also)  be  able  to  ob¬ 
tain  the  keys  from  the  escrow  agent.42 

The  USCIB  has  also  identified  a  number  of 
distinctive  business  concerns  with  respect  to  the 
U.S.  government’s  position  on  encryption  and 
liability: 

■  uncertainty  regarding  whether  the  Clinton 
Administration  might  authorize  strict  gov¬ 
ernment  liability  for  misappropriation  of 
keys,  including  adoption  of  tamperproof 
measures  to  account  for  every  escrowed  unit 
key  and  family  key  (see  box  2-3); 

■  the  degree  of  care  underlying  design  of  Skip¬ 
jack,  EES,  and  Capstone  (given  the  govern¬ 
ment’s  still-unresolved  degree,  if  any,  of 
liability); 

■  the  confusion  concerning  whether  the  gov¬ 
ernment  intends  to  disclaim  all  liability  in 
connection  with  the  EES  and  Capstone  initia- 


39  Ibid.,  pp.  3-4. 

40  United  States  Council  for  International  Business,  “Business  Requirements  for  Encryption,”  New  York,  NY,  Oct.  10,  1994. 

41  United  States  Council  for  International  Business,  “Liability  Issues  and  the  U.S.  Administration’s  Encryption  Initiatives,”  New  York,  NY, 
Nov.  2,  1994, 

42  USCIB,  op.  cit.,  footnote  40,  pp.  3-4. 
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tives,  and  the  extent  to  which  family  keys, 
unit  keys,  and  law  enforcement  decryption 
devices  will  be  adequately  secured;  and 
■  uncertainties  regarding  the  liability  of  non¬ 
governmental  parties  (e.g.,  chip  manufactur¬ 
ers,  vendors,  and  their  employees)  for 
misconduct  or  negligence.43 

These  types  of  concerns  have  remained  unre¬ 
solved  (see  related  discussion  and  options  pres¬ 
ented  in  the  1994  OTA  report,  pp.  16-18  and 
171-182). 

Liability  issues  are  important  to  the  develop¬ 
ment  of  electronic  commerce  and  the  underpin¬ 
ning  institutional  infrastructures,  including  (but 
not  limited  to)  escrow  agents  for  key-escrowed 
encryption  systems  and  certificate  authorities  for 
public-key  infrastructures.  Widespread  use  of  cer¬ 
tificate-based  public-key  infrastructures  will  re¬ 
quire  resolution  and  harmonization  of  liability 
requirements  for  trusted  entities,  whether  these  be 
federal  certificate  authorities,  private  certificate 
(or  “certification”)  authorities,  escrow  agents, 
banks,  clearinghouses,  value-added  networks,  or 
other  entities.44 

There  is  increasing  momentum  toward  frame¬ 
works  within  which  to  resolve  legal  issues  per¬ 
taining  to  digital  signatures  and  to  liability.  For 
example: 

■  The  Science  and  Technology  Section  of  the 
American  Bar  Association’s  Information  Secu¬ 


rity  Committee  is  drafting  “Global  Digital  Sig¬ 
nature  Guidelines”  and  model  digital-signature 
legislation. 

■  With  participation  by  the  International  Cham¬ 
ber  of  Commerce  and  the  U.S.  State  Depart¬ 
ment,  the  United  Nations  Commission  on 
International  Trade  Law  has  completed  a  Mod¬ 
el  Law  on  electronic  data  interchange  (EDI). 

■  Utah  has  just  enacted  digital  signature  legisla¬ 
tion.45 

The  Utah  Digital  Signature  Act46  is  intended  to 
provide  a  reliable  means  for  signing  computer- 
based  documents  and  legal  recognition  of  digital 
signatures  using  “strong  authentication  tech¬ 
niques”  based  on  asymmetric  cryptography.  To 
assure  a  minimum  level  of  reliability  in  digital 
signatures,  the  Utah  statute  provides  for  the  li¬ 
censing  and  regulation  of  certification  authorities 
by  a  “Digital  Signature  Agency”  (e.g.,  the  Divi¬ 
sion  of  Corporations  and  Commercial  Code  of  the 
Utah  Department  of  Commerce).  The  act,  first 
drafted  as  a  proposed  model  law,  provides  that  the 
private  key  is  the  property  of  the  subscriber  who 
rightfully  holds  it  (and  who  has  a  duty  to  keep  it 
confidential);  thus,  tort  or  criminal  actions  are 
possible  for  theft  or  misuse.  It  is  technology-inde¬ 
pendent;  that  is,  it  does  not  mandate  use  of  a  spe¬ 
cific  signature  technique.47  The  management  of 
the  system  described  in  the  Utah  statute  can  easily 


43  USCIB,  op.  cit.,  footnote  41,  pp.  2-6. 

44  See  footnote  13  for  discussion  of  liability  exposure,  legal  considerations,  tort  and  contract  remedies,  government  consent  to  be  liable,  and 
recommendations  and  approaches  to  mitigate  liability. 

45  Information  on  the  American  Bar  Association  and  United  Nations  activities  provided  by  Michael  Baum,  Principal,  Independent  Monitor¬ 
ing,  personal  communication.  Mar.  1 9, 1 995.  See  also  Michael  S.  Baum,  Federal  Certification  Authority  Liability  and  Policy:  Law  and  Policy  of 
Certificate-Based  Public  Key  and  Digital  Signatures ,  NIST-GCR-94-654,  NTIS  Doc.  No.  PB94- 1 9 1  -202  (Springfield,  VA:  National  Technical 
Information  Service,  1994). 

46  Utah  Digital  Signature  Legislative  Facilitation  Committee,  “Utah  Digital  Signature  Legislation,”  Dec.  21, 1994.  The  Utah  Digital  Signa¬ 
ture  Act  was  signed  into  law  on  March  10,  1995,  as  section  46-3-101  et  seq.,  Utah  Code  Annotated .  (Prof.  Lee  Hollaar,  University  of  Utah, 
personal  communication,  Mar.  22,  1995.) 

47  Utah  Digital  Signature  Act,  ibid.  The  model  legislation  was  endorsed  by  the  American  Bar  Association,  Information  Security  Committee 
of  the  Science  and  Technology  Section,  EDI/Information  Technology  Division;  Prof.  Lee  Hollaar,  University  of  Utah;  Salt  Lake  Legal  Defend¬ 
ers  Assoc.;  Statewide  Association  of  Public  Attorneys;  Utah  Attorney  General’s  Office;  Utah  Dept,  of  Corrections;  Utah  Information  Technolo¬ 
gy  Commission;  Utah  Judicial  Council;  and  Utah  State  Tax  Commission. 


88 1  Issue  Update  on  Information  Security  and  Privacy  in  Network  Environments 


be  privatized  and  globalized.48  The  information  at 
the  Digital  Signature  Agency  can  be  as  little  as  the 
authorization  of  one  or  more  private  sector  certifi¬ 
cate  authorities;  a  certificate  authority  can  operate 
in  many  states,  having  authorizations  for  each.49 

UPDATE  ON  PRIVACY  LEGISLATION 

In  the  104th  Congress,  bills  have  been  introduced 
to  address  the  privacy-related  issues  of  search  and 
seizure,  access  to  personal  records,  content  of 
electronic  information,  drug  testing,  and  im¬ 
migration  and  social  security  card  fraud  problems. 
In  addition,  Representative  Cardiss  Collins  has  re¬ 
introduced  legislation  (H.R.  184)  to  establish  a 
Privacy  Protection  Commission. 

The  “Individual  Privacy  Protection  Act  of  1995” 
(H.R.  184)  is  identical  to  legislation  Representa¬ 
tive  Collins  introduced  in  the  103rd  Congress 
(H.R.  135).  Both  bills  are  similar  to  legislation 
introduced  in  the  103rd  Congress  by  Senator  Paul 
Simon  (S.  1735).  The  establishment  of  a  Privacy 
Protection  Commission  was  endorsed  by  the  Vice 
President’s  National  Performance  Review  and  en¬ 
couraged  in  a  1993  statement  by  Sally  Katzen,  the 
Administrator  of  the  Office  of  Information  and 
Regulatory  Affairs  in  the  Office  of  Management 
and  Budget.50  H.R.  184  would  establish  a  five- 
member  Privacy  Protection  Commission  charged 
with  ensuring  the  privacy  rights  of  U.S.  citizens, 
providing  advisory  guidance  on  matters  related  to 
electronic  data  storage,  and  promoting  and  en¬ 
couraging  the  adoption  of  fair  information  prac¬ 
tices  and  the  principle  of  collection  limitation. 

Immigration  concerns  and  worker  eligibility  are 
prompting  reexamination  of  social  security  card 
fraud  and  discussion  over  a  national  identification 
database.  At  least  eight  bills  have  been  introduced 


in  the  104th  Congress  to  develop  tamper-proof  or 
counterfeit-resistant  social  security  cards  (H.R. 
560,  H.R.  570,  H.R.  756,  H.R.  785)  and  to  pro¬ 
mote  research  toward  a  national  identification  da¬ 
tabase  (H.R.  502,  H.R.  195,  S.  456,  S.  269). 

Four  bills  have  been  introduced  modifying 
search  and  seizure  limitations:  H.R.  3,  H.R.  666, 
S.  3,  and  S.  54.  The  “Exclusionary  Rule  Reform 
Act  of  1995”  (H.R.  666  and  companion  S.  54), 
which  revises  the  limitations  on  evidence  found 
during  a  search,  passed  the  House  on  February  10, 
1995.  Similar  provisions  have  been  included  in 
crime  legislation  introduced  in  both  Houses,  S.  3 
and  H.R.  3.  The  Senate  Committee  on  the  Judicia¬ 
ry  has  held  a  hearing  on  Title  V  of  S.  3,  the  provi¬ 
sions  reforming  the  exclusionary  rule. 

Also  this  session,  legislation  has  been  intro¬ 
duced  increasing  privacy  protection  by  restricting 
the  use  or  sale  of  lists  collected  by  communication 
carriers  (H.R.  411)  and  the  U.S.  Postal  Service 
(H.R.  434),  defining  personal  medical  privacy 
rights  (H.R.  435,  S.  7),  detailing  acceptable  usage 
of  credit  report  information  (H.R.  561),  and  man¬ 
dating  procedures  for  determining  the  reliability 
of  drug  testing  (H.R.  153).  These  bills  establish 
guidelines  in  specific  areas,  but  do  not  attempt  to 
address  the  overall  challenges  facing  privacy 
rights  in  an  electronic  age. 

The  “Family  Privacy  Bill”  (H.R.  1271)  passed 
the  House  on  April  4,  1995.  H.R.  1271, 
introduced  by  Representative  Steve  Horn  on 
March  21 , 1995,  is  intended  to  provide  parents  the 
right  to  supervise  and  choose  their  children’s  par¬ 
ticipation  in  any  federally  funded  survey  or  ques¬ 
tionnaire  that  involves  intrusive  questioning  on 
sensitive  issues.51  Some  have  raised  concerns 
about  the  bill  on  the  grounds  that  it  might  danger- 


48  The  Utah  act  envisions  use  of  signatures  based  on  standards  similar  to  or  including  the  ANSI  X.9.30  or  ITU  X.509  standards  (ibid.). 

49  Prof.  Lee  Hollaar,  University  of  Utah,  personal  communication,  Mar.  22,  1995. 

50  Statement  by  Sally  Katzen,  Administrator,  Office  of  Information  and  Regulatory  Affairs,  OMB  and  Chair,  Information  Policy  Commit¬ 
tee,  Information  Infrastructure  Task  Force,  Nov.  18th,  1993  ( Congressional  Record ,  p.  S.5131). 

51  Representative  Scott  Mclnnis,  Congressional  Record ,  Apr.  4,  1995,  p.  H4126. 
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ously  limit  local  police  authority  to  question  mi¬ 
nors  and  threaten  investigations  of  child  abuse,  or 
hinder  doctors  in  obtaining  timely  patient  in¬ 
formation  on  children.52 

In  addition,  the  Office  of  Management  and 
Budget  recently  published  notice  of  “Draft  Prin¬ 
ciples  for  Providing  and  using  Personal  Informa¬ 
tion  and  Commentary.53”  These  were  developed 
by  the  Information  Infrastructure  Task  Force’s 
Working  Group  on  Privacy  and  are  intended  to  up¬ 
date  and  revise  the  Code  of  Fair  Information  Prac¬ 
tices  that  was  developed  in  the  early  1970s  and 
used  in  development  of  the  Privacy  Act  of  1974. 

UPDATE  ON  INFORMATION-SECURITY 
POLICY  INITIATIVES  AND  LEGISLATION 

The  Defense  Department’s  “Information  Warfare” 
activities  address  the  opportunities  and  vulnera¬ 
bilities  inherent  in  its  (and  the  country’s)  increas¬ 
ing  reliance  on  information  and  information 
systems.  There  are  a  variety  of  Information  War¬ 
fare  activities  ongoing  in  Department  services  and 
agencies,  the  Office  of  the  Secretary  of  Defense, 
and  elsewhere 54  The  Department’s  Defensive 
Information  Warfare  program  goals  focus  on  tech¬ 
nology  development  to  counter  vulnerabilities 
stemming  from  its  growing  dependence  on 
information  systems  and  the  commercial  informa¬ 
tion  infrastructure  (e.g.,  the  public-switched  net¬ 
work  and  the  Internet).  The  Information  Systems 
Security  Research  Joint  Technology  Office  estab¬ 
lished  by  ARPA,  DIS  A,  and  NS  A  (see  above)  will 
pursue  research  and  development  pursuant  to 
these  goals. 

The  increasing  prominence  of  Information  War¬ 
fare  issues  has  contributed  to  an  increasing  mo¬ 


mentum  for  consolidating  information-security 
authorities  government-wide,  thereby  increasing 
the  role  of  the  defense  and  intelligence  agencies 
for  unclassified  information  security  overall: 

Protection  of  U.S.  information  systems  is 
also  clouded  by  legal  restrictions  put  forth,  for 
example,  in  the  Computer  Security  Act  of  1987. 

Of  concern  to  the  Task  Force  is  the  fact  that 
IW  [Information  Warfare]  technologies  and  ca¬ 
pabilities  are  largely  being  developed  in  an  open 
commercial  market  and  are  outside  of  direct 
Government  control  55 

Such  a  consolidation  and/or  expansion  would  run 
counter  to  current  statutory  authorities  and  to  the 
Office  of  Management  and  Budget  the  Office  of 
Management  and  Budget  (OMB’s)  proposed  new 
government-wide  security  and  privacy  policy- 
guidance  (see  below). 

I  The  Joint  Security  Commission 

In  mid-1993,  the  Joint  Security  Commission  was 
convened  by  the  Secretary  of  Defense  and  the  Di¬ 
rector  of  Central  Intelligence  to  develop  a  “new 
approach  to  security  that  would  assure  the  adequa¬ 
cy  of  protection  within  the  contours  of  a  security 
system  that  is  simplified,  more  uniform,  and  more 
cost  effective.”56  The  Joint  Security  Commis¬ 
sion’s  report  made  recommendations  across  a 
comprehensive  range  of  areas,  including: 

■  classification  management; 

■  threat  assessments; 

■  personnel  security  and  the  clearance  process; 

■  physical,  technical,  and  procedural  security; 

■  protection  of  advanced  technologies; 

■  a  joint  investigative  service; 

■  accounting  for  the  costs  of  security; 


52  Representative  Cardiss  Collins,  Congressional  Record ,  Apr.  4,  1995,  p.  H4126. 

53  Federal  Register ,  Jan.  20,  1995,  pp.  4362-4370. 

54  See,  e.g.  Office  of  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology,  “Report  of  the  Defense  Science  Board  Summer  Study 
Task  Force  on  Information  Architecture  for  the  Battlefield,”  October  1994. 

55  Ibid.,  p.  52. 

56  Joint  Security  Commission,  Redefining  Security :  A  Report  to  the  Secretary  of  Defense  and  Director  of  Central  Intelligence ,  Feb.  28, 1 994 
(quote  from  letter  of  transmittal).  See  also  U.S.  Congress,  House  of  Representatives,  Permanent  Select  Committee  on  Intelligence,  “Intelligence 
Authorization  Act  for  Fiscal  Year  1994,”  Rept.  103-162,  Part  I,  103d  Congress,  1st  session,  June  29,  1993,  pp.  26-27. 
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■  security  awareness,  training,  and  education; 

■  information  systems  security;  and 

■  a  security  architecture  for  the  future  [empha¬ 
sis  added].57 

The  Joint  Security  Commission  report’s  sec¬ 
tions  on  information  systems  security58  and  a  se¬ 
curity  architecture  for  the  future59  are  of  special 
interest.  In  the  context  of  its  charter,  the  Commis¬ 
sion  proposes  a  unified  security  policy  structure 
and  authority  for  classified  and  unclassified  in¬ 
formation  in  the  defense/intelligence  communi¬ 
ty.60  However,  the  report  also  recommends  a  more 
general  centralization  of  information  security 
along  these  lines  government- wide;  the  executive 
summary  highlights  the  conclusion  that  the  secu¬ 
rity  centralization  within  the  defense/intelligence 
community  described  in  the  report  should  be  ex¬ 
tended  government-wide.61  The  report  also  rec¬ 
ommends  “establishment  of  a  national  level 
security  policy  committee  to  provide  structure  and 
coherence  to  U.S.  Government  security  policy, 
practices  and  procedures.”62 

I  The  Security  Policy  Board 

On  September  16, 1994,  President  Clinton  signed 
Presidential  Decision  Directive  29  (PDD-29). 
PDD-29,  “Security  Policy  Coordination,”  estab¬ 
lished  a  new  structure,  under  the  direction  of  the 
National  Security  Council  (NSC),  for  the  coor¬ 
dination,  formulation,  evaluation,  and  oversight 
of  U.S.  security  policy.62  According  to  the  de¬ 
scription  of  PDD-29  provided  to  OTA  by  NSC, 
the  directive  designates  the  former  Joint  Security 
Executive  Committee  established  by  the  Secre¬ 


tary  of  Defense  and  the  Director  of  Central  Intelli¬ 
gence  as  the  Security  Policy  Board. 

The  Security  Policy  Board  (SPB)  subsumes  the 
functions  of  a  number  of  previous  national  securi¬ 
ty  groups  and  committees.  The  SPB  members  in¬ 
clude  the  Director  of  Central  Intelligence,  Deputy 
Secretary  of  Defense,  Vice  Chairman  of  the  Joint 
Chiefs  of  Staff,  Deputy  Secretary  of  State,  Under 
Secretary  of  Energy,  Deputy  Secretary  of  Com¬ 
merce,  and  Deputy  Attorney  General;  plus  one 
Deputy  Secretary  from  “another  non-defense  re¬ 
lated  agency”  selected  on  a  rotating  basis,  and  one 
representative  each  from  OMB  and  NSC  staff. 

The  Security  Policy  Forum  that  had  been  estab¬ 
lished  under  the  Joint  Security  Executive  Com¬ 
mittee  was  retained  under  the  SPB.  The  forum  is 
composed  of  senior  representatives  from  over  two 
dozen  defense,  intelligence,  and  civilian  agencies 
and  departments;  the  forum  chair  is  appointed  by 
the  SPB  chair.  The  Security  Policy  Forum  func¬ 
tions  are  to:  consider  security  policy  issues  raised 
by  its  members  or  others,  develop  security  policy 
initiatives  and  obtain  comments  for  the  SPB  from 
departments  and  agencies,  evaluate  the  effective¬ 
ness  of  security  policies,  monitor  and  guide  the 
implementation  of  security  policies  to  ensure  co¬ 
herence  and  consistency,  and  oversee  application 
of  security  policies  to  ensure  they  are  equitable 
and  consistent  with  national  goals.64 

PDD-29  also  established  a  Security  Policy  Ad¬ 
visory  Board  of  five  members  from  industry.  This 
independent,  nongovernmental  advisory  board  is 
intended  to  advise  the  President  on  implementa¬ 
tion  of  the  policy  principles  guiding  the  “new” 


57  Joint  Security  Commission,  ibid. 

58  Ibid.,  pp.  101-113. 

59  Ibid.,  pp.  127  et  seq. 

60  Ibid.,  p.  105,  first  paragraph.;  p.  110,  recommendation;  pp.  127-130. 

61  Ibid.,  p.  viii,  top. 

62  Ibid.,  p.  130. 

63  Although  it  is  unclassified,  PDD-29  has  not  been  released.  This  discussion  is  based  on  a  fact  sheet  provided  to  OTA  by  NSC;  the  fact  sheet 
is  said  to  be  a  “nearly  verbatim  text  of  the  PDD,”  with  the  only  differences  being  “minor  grammatical  ones.”  David  S.  Van  Tassel  (Director, 
Access  Management,  NSC),  letter  to  Joan  Winston  (OTA)  and  enclosure,  Feb.  16,  1995. 

64  Ibid,  (fact  sheet). 
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formulation,  evaluation,  and  oversight  of  U.S.  se¬ 
curity  policy,  and  to  provide  the  SPB  and  the  intel¬ 
ligence  community  with  a  “public  interest” 
perspective.  The  SPB  is  authorized  to  establish  in¬ 
teragency  working  groups  as  necessary  to  carry 
out  its  functions  and  to  ensure  interagency  input  to 
and  coordination  of  security  policy,  procedures, 
and  practices,  with  staffs  to  support  the  SPB  and 
any  other  groups  or  fora  established  pursuant  to 
PDD-29. 

PDD-29  was  not  intended  to  change  or  amend 
existing  authorities  or  responsibilities  of  the 
members  of  the  SPB,  as  “contained  in  the  Nation¬ 
al  Security  Act  of  1947,  other  existing  laws  or 
Executive  Orders.”65  PDD-29  does  not  refer  spe¬ 
cifically  to  government  information  security 
policy,  procedures,  and  practices,  or  to  unclassi¬ 
fied  information  security  government- wide.  Nev¬ 
ertheless,  the  proposed  detailed  implementation 
of  the  directive  with  respect  to  information  securi¬ 
ty,  as  articulated  in  the  Security  Policy  Board’s 
staff  report,  “Creating  a  New  Order  in  U.S.  Securi¬ 
ty  Policy,”  is  a  departure  from  the  information  se¬ 
curity  structure  set  forth  in  the  Computer  Security 
Act  of  1987.  The  SPB  staff  report  appears  to  rec¬ 
ognize  this  mismatch  between  its  proposal  and 
statutory  authorities  for  unclassified  information 
security,  noting  the  Computer  Security  Act  under 
information-security  “actions  required”  to  imple¬ 
ment  PDD-29.66 

The  SPB  staff  report’s  proposed  “new  order”  for 
information  security  builds  on  the  Joint  Security 
Commission’s  analysis  and  recommendations  to 
establish  a  “unifying  body”  government-wide.67 
With  respect  to  information  security,  the  new  SPB 
structure  would  involve  organizing  an  Informa¬ 
tion  Systems  Security  Committee  (ISSC)  charged 
with  “coupling  the  development  of  policy  for  both 


the  classified  and  the  sensitive  but  unclassified 
communities.”  The  SPB  staff  report  generally 
notes  that: 

Realignment  into  this  new  structure  will  re¬ 
quire  a  transition  effort  that  will  include  the  nec¬ 
essary  coordination  to  effect  changes  to  several 
executive  and  legislative  edicts. 

...  An  endorsement  of  this  proposed  reorga¬ 
nization  will  include  authorization  for  the  Di¬ 
rector,  Board  Staff  to  proceed  with  the 
establishment  of  a  transition  team  and  coordi¬ 
nate  all  activities  necessary  to  effect  the  U.S. 
Government’s  conversion  to  this  new  struc¬ 
ture68 

As  motivation  for  the  changes,  the  SPB  staff  re¬ 
port  notes  that: 

Nowhere  in  the  proposed  new  order  does  the 
goal  to  create  cohesive,  cost-effective,  and  op¬ 
erationally  effective  security  policy  encounter  a 
greater  challenge  than  in  the  area  of  protecting 
information  systems  and  networks.  The  national 
architecture  under  development  will  provide 
vast  amounts  of  information  to  all  consumers 
rapidly  and  for  a  reasonable  price.  The  ability  to 
link  and  communicate  with  a  wide  variety  of 
networks  will  not  only  be  a  key  to  productivity 
but  will  also  be  an  “Achilles  heel.”  Some  of  this 
nation’s  most  significant  vulnerabilities  lie 
within  the  sensitive  but  unclassified  networks 
that  perform  the  basic  function  that  we  all  take 
for  granted.  The  coupling  of  policy  require¬ 
ments  for  sensitive  but  unclassified  systems 
within  those  for  classified  systems  dictates  the 
need  for  a  comprehensive  structure  to  address 
these  needs  in  a  cohesive  fashion.69 

This  “comprehensive  structure”  would  be  the  new 
Information  Systems  Security  Committee 
(ISSC),  which  would  be: 


65  Ibid. 

66  U.S.  Security  Policy  Board  Staff,  “Creating  a  New  Order  in  U.S.  Security  Policy,”  Nov.  21,  1994.  p.  18. 

67  Ibid.,  p.  3.  See  Elizabeth  Sikorovsky,  “NSC  Proposes  To  Shift  Policy-Making  Duties,”  Federal  Computer  Week ,  Jan.  23, 1995,  pp.  1 , 45. 
See  also  Kevin  Power,  “Administration  Floats  New  Information  Security  Policy,”  Government  Computer  News,  Jan.  23,  1995,  p.  59. 

68  U.S.  Security  Policy  Board  Staff ,  op.  cit.,  footnote  66,  p.  II-III. 

69  Ibid.,  p.  15. 
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. .  .based  on  the  foundation  of  the  current 
NSTISSC  [National  Security  Telecommunica¬ 
tions  and  Information  Systems  Security  Com¬ 
mittee,  see  appendix  B]  but  will  have 
responsibility  for  both  the  classified  and  the  sen¬ 
sitive  but  unclassified  world. 

The  IS  SC  would  be  jointly  chaired  at  the  SES 
[Senior  Executive  Service]  or  General  Officer 
level  by  DOD  and  OMB.  This  new  body  would 
consist  of  voting  representatives  from  each  of 
the  agencies/departments  currently  represented 
on  the  NSTISSC  and  its  two  subcommittees, 
NIST  and  the  civil  agencies  it  represents,  and 
other  appropriate  agencies/departments,  such  as 
DISA,  which  are  currently  not  represented  on 
the  NSTISSC.  This  body  would  create  working 
groups  as  needed  to  address  topics  of  interest. 

The  ISSC  would  eventually  have  authority 
over  all  classified  and  unclassified  but  sensitive 
systems,  and  would  report  to  through  the  [Secu¬ 
rity  Policy]  Forum  and  Board  to  the  NSC.  Thus, 
policies  would  have  the  full  force  and  authority 
of  an  NSC  Directive,  rather  than  the  relatively 
“toothless”  issuances  currently  emanating  from 
the  NSTISSC.  NSA  would  continue  to  provide 
the  secretariat  to  the  new  national  INFOSEC 
[Information  Security]  structure,  since  the  sec¬ 
retariat  is  a  well-functioning,  highly-efficient, 
and  effective  body. 

. .  .A  joint  strategy  would  have  to  be  devised 
for  a  smooth  transition  between  the  current  and 
new  structures,  which  would  ensure  that  current 
momentum  is  maintained  and  continuity  pre¬ 
served.  In  addition ,  a  new  definition  must  be  de¬ 
veloped  for  “national  security  information ,  ” 
and  it  must  be  determined  how  such  information 
relates  to  the  unclassified  arena  from  a  national 
security  standpoint  [emphasis  added].  Issues 
such  as  voting  in  such  a  potentially  unwieldy  or¬ 
ganization  must  also  be  resolved.70 


At  this  writing,  the  extent  to  which  the  SPB 
information  security  proposals,  ISSC,  and  the 
development  of  a  new  definition  of  “national  se¬ 
curity  information”  have  or  have  not  been  “en¬ 
dorsed”  within  the  executive  branch  is  unclear. 
Outside  the  executive  branch,  however,  the  pro¬ 
posals  have  been  met  with  concern  and  dismay 
reminiscent  of  reactions  to  National  Security  De¬ 
cision  Directive- 145  (NSDD-145)  a  decade  ago 
(see  chapter  2  and  appendix  B).71  Moreover,  they 
run  counter  to  the  statutory  agency  authorities  set 
forth  in  the  104th  Congress  in  the  Paperwork  Re¬ 
duction  Act  of  1995  (see  below),  as  well  as  those 
in  the  Computer  Security  Act  of  1987. 

At  its  March  23-24, 1995  meeting,  the  Comput¬ 
er  Systems  Security  and  Privacy  Board  that  was 
established  by  the  Computer  Security  Act  issued 
Resolution  95-3,  recommending  that  the  SPB 
await  broader  discussion  of  issues  before  proceed¬ 
ing  with  its  plans  “to  control  unclassified,  but  sen¬ 
sitive  systems.” 

Concerns  have  also  been  expressed  within  the 
executive  branch.  The  ISSC  information-security 
structure  that  would  increase  the  role  of  the  de¬ 
fense  and  intelligence  communities  in  govern¬ 
ment-wide  unclassified  information  security  runs 
counter  to  the  Clinton  Administration’s  “basic  as¬ 
sumptions”  about  free  information  flow  and  pub¬ 
lic  accessibility  as  articulated  in  the  1993  revision 
of  OMB  Circular  A- 1 30,  “Management  of  Federal 
Information  Resources.”72 

Moreover,  some  senior  federal  computer  securi¬ 
ty  managers  have  expressed  concern  about  what 
they  consider  premature  implementation  of  the 
SPB  staff  report’s  proposed  centralization  of  in¬ 
formation-security  functions  and  responsibilities. 
In  a  January  11,  1995,  letter  to  Sally  Katzen,  Ad¬ 
ministrator,  Office  of  Information  and  Regulatory 


70  Ibid.,  pp.  17-18.  See  appendix  C  of  this  paper  and  OTA,  op.  cit.,  footnote  1,  pp.  132-148  for  discussion  of  NSDD-145,  the  intent  of  the 
Computer  Security  Act  of  1987,  and  NSTISSC. 

71  See  Neil  Munro,  “White  House  Security  Panels  Raise  Hackles,”  Washington  Technology,  Feb.  23,  1995,  pp.  6,8. 

72  OMB  Circular  A- 130 — Revised,  June  25,  1993,  Transmittal  Memorandum  No.  1,  sec.  7. 
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Affairs  (released  March  23,  1995),  the  Steering 
Committee  of  the  Federal  Computer  Security  Pro¬ 
gram  Manager’s  Forum73  indicated  “unanimous 
disagreement”  with  the  Security  Policy  Board’s 
proposal  and  urged  OMB  to  “take  appropriate  ac¬ 
tion  to  restrict  implementation  of  the  SPB  report 
to  only  classified  systems”  for  the  following  rea¬ 
sons: 

1.  The  establishment  of  a  national  security 
community  dominated  Information  System 
Security  Committee  having  jurisdiction  for 
both  classified  and  unclassified  systems  is 
contrary  to  the  Computer  Security  Act.  Fur¬ 
thermore,  it  is  not  consistent  with  the  author¬ 
ity  of  PDD-29  which  requires  coordination 
of  national  security  policy  [emphasis  add¬ 
ed]. 

2.  This  initiative  also  undercuts  a  stated  Ad¬ 
ministration  goal  for  an  “open  government” 
in  which  the  free  flow  of  information  is  facil¬ 
itated  by  removing  government  restrictions 
and  regulations.  For  example,  the  SPB  docu¬ 
ment  states  that  a  priority  project  for  the  new 
committee  will  be  to  craft  a  broad  new  defi¬ 
nition  for  “national  security  related  informa¬ 
tion.”  This  will  be  viewed  by  many  as  an 
attempt  to  impose  new  restrictions  on  access 
to  government  information. 

3.  The  SPB  proposal  may  serve  to  increase 
concerns  over  the  government’s  intentions 
in  the  field  of  information  security.  We  know 
from  observing  the  public  debate  over 
NSDD-145  and  the  Clipper  Chip  that  the  pri¬ 
vate  sector  deeply  mistrusts  the  intentions  of 
the  government  to  use  information  security 
policy  as  a  lever  to  further  goals  and  objec¬ 
tives  viewed  as  contrary  to  the  interests  of 
the  business  community.  Congress  passed 
the  Computer  Security  Act  of  1987  in  re¬ 
sponse  to  expressions  of  displeasure  from 


the  private  sector  regarding  the  unwelcome 
overtures  by  the  national  security  communi¬ 
ty  towards  “assisting”  the  private  sector  un¬ 
der  the  auspices  of  national  security.  This 
was  perceived  as  having  a  significant  ad¬ 
verse  impact  upon  personal  privacy,  com¬ 
petitiveness  and  potential  trade  markets. 

4.  We  believe  that  it  is  inappropriate  for  the  na¬ 
tional  security  and  intelligence  communi¬ 
ties  to  participate  in  selecting  security 
measures  for  unclassified  systems  at  civilian 
agencies.  Their  expertise  in  protecting  na¬ 
tional  security  systems  is  not  readily  trans¬ 
ferable  to  civil  agency  requirements.  The 
primary  focus  of  security  in  the  classified 
arena  is  directed  towards  protecting  the  con¬ 
fidentiality  of  information  with  little  con¬ 
cern  for  cost  effectiveness.  Unclassified 
systems,  however,  which  constitute  over 
90%  of  the  government’s  IT  [information 
technology]  assets,  have  significantly  fewer 
requirements  for  confidentiality  vis-a-vis 
the  need  for  integrity  and  availability.  In 
these  times  of  diminishing  resources,  cost- 
effectiveness  is  of  paramount  concern  in  the 
unclassified  arena  74 

The  letter  concludes: 

The  Steering  Committee  is  most  concerned 
that  the  report  is  being  misrepresented  as  Ad¬ 
ministration  policy.  Indicative  of  this  is  that 
“transition  teams”  are  being  formed  to  imple¬ 
ment  the  report. 

Please  consider  these  facts  and  take  action  to 
restrict  the  SPB  report  implementation  to  only 
classified  systems.75 

This  type  of  restriction  appears  to  have  been  incor¬ 
porated  in  the  proposed  revision  to  Appendix  III 
of  OMB  Circular  A- 130  (see  below). 


73  The  Federal  Computer  Security  Program  Manager’s  Forum  is  made  up  of  senior  computer  security  managers  for  civilian  agencies,  in¬ 
cluding  the  Departments  of  Commerce,  Health  and  Human  Services,  Justice,  and  Transportation.  The  Jan.  11, 1995,  letter  to  Sally  Katzen  was 
signed  by  Lynn  McNulty,  Forum  Chair  (National  Institute  of  Standards  and  Technology)  and  Sadie  Pitcher,  Forum  Co-chair  (Department  of 
Commerce).  Text  of  letter  taken  from  the  online  EPIC  Alert ,  vol.  2.05,  Mar.  27,  1995. 

74  Ibid. 

75  Ibid. 
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In  March  and  April  1995,  OTA  invited  the  Se¬ 
curity  Policy  Board  staff  to  comment  on  draft 
OTA  text  discussing  information-security  central¬ 
ization,  including  the  Joint  Security  Commission 
report,  PDD-29,  and  the  SPB  staff  report.  OTA  re¬ 
ceived  SPB  staff  comments  in  early  May  1995,  as 
this  background  paper  was  in  press.  According  to 
the  Security  Policy  Board  staff  director,  informa¬ 
tion  systems  security  policy  is  a  “work  in  progress 
in  its  early  stages”  for  the  SPB  and  the  staff  report 
was  intended  to  be  a  “strawman”  starting  point  for 
discussion.  Moreover,  according  to  the  SPB  staff, 
“recognizing  the  sensitivity  and  complexity  of  In¬ 
formation  Systems  Security  policy,  the  ISSC  was 
not  one  of  the  committees  which  was  established, 
nor  was  a  transition  team  formed.76”  In  order  to 
provide  as  much  information  as  possible  for  con¬ 
sideration  of  information  security  issues,  includ¬ 
ing  the  SPB  staff  perspective,  OTA  has  included 
the  SPB  staff  comments  in  box  1-3  on  page  30. 

I  The  Paperwork  Reduction  Act  of  1995 

The  Paperwork  Reduction  Act  was  reauthorized 
in  the  104th  Congress.  The  House  and  Senate  ver¬ 
sions  of  the  Paperwork  Reduction  Act  of  1995 
(H.R.  830  and  S.244)  both  left  existing  agency  au¬ 
thorities  under  the  Computer  Security  Act  of  1 987 
unchanged.77  The  Paperwork  Reduction  Act  of 
1995  (Public  Law  104-13)  was  reported  on  April 
3,  199578  and  passed  in  both  Houses  on  April  6, 
1995. 


Among  its  goals,  the  Paperwork  Reduction  Act 
of  1995  is  intended  to  make  federal  agencies  more 
responsible  and  publicly  accountable  for  informa¬ 
tion  management.  With  respect  to  safeguarding 
information,  the  act  seeks  to: 

. .  .ensure  that  the  creation,  collection,  main¬ 
tenance,  use,  dissemination,  and  disposition  of 
information  by  or  for  the  Federal  Government  is 
consistent  with  applicable  laws,  including  laws 
relating  to — 

(A)  privacy  and  confidentiality,  including  sec¬ 
tion  552a  of  Title  5; 

(B)  security  of  information,  including  the  Com¬ 
puter  Security  Act  of  1987  (Public  Law 
100-235);  and 

(C)  access  to  information,  including  section 
552  of  Title  5  79 

With  respect  to  privacy  and  security,  the  Paper¬ 
work  Reduction  Act  of  1995  provides  that  the  Di¬ 
rector  of  OMB  shall: 

1.  develop  and  oversee  the  implementation  of 
policies,  principles,  standards,  and  guide¬ 
lines  on  privacy,  confidentiality,  security, 
disclosure,  and  sharing  of  information  col¬ 
lected  or  maintained  by  or  for  agencies; 

2.  oversee  and  coordinate  compliance  with 
sections  552  and  552a  of  title  5,  the  Comput¬ 
er  Security  Act  of  1987  (40  U.S.C.  759  note), 
and  related  information  management  laws; 
and 

3.  require  Federal  agencies,  consistent  with  the 
Computer  Security  Act  of  1987  (40  U.S.C. 


76  Peter  D.  Saderholm  (Director,  Security  Policy  Board  Staff),  memorandum  for  Joan  D.  Winston  and  Miles  Ewing  (OTA),  SPB  095-95, 
May  4,  1995. 

77  Senator  William  V.  Roth,  Jr.,  Congressional  Record ,  Mar.  6,  1995,  p.  S3512. 

78  U.S.  Congress,  House  of  Representatives,  “Paperwork  Reduction  Act  of  1995— Conference  Report  to  Accompany  S.244,”  H.  Rpt. 
104-99,  Apr,  3, 1995.  As  the  “Joint  Explanatory  Statement  of  the  Committee  of  the  Conference”  (ibid.,  pp.  27-39)  notes,  the  1995  act  retains  the 
legislative  history  of  the  Paperwork  Reduction  Act  of  1 980.  Furthermore,  the  definition  of  “information  technology”  in  the  1995  act  is  intended 
to  preserve  the  exemption  for  military  and  intelligence  information  technology  that  is  found  in  current  statutory  definitions  of  “automatic  data 
processing.”  The  1995  act  accomplishes  this  by  referring  to  the  so-called  Warner  Amendment  exemptions  to  the  Brooks  Act  of  1965  and,  thus, 
to  section  1 1 1  of  the  Federal  Property  and  Administrative  Services  Act  (ibid.,  pp.  28-29).  See  also  discussion  of  the  Warner  Amendment  exemp¬ 
tions  from  the  FIPS  and  the  Computer  Security  Act  in  appendix  B  of  this  paper. 

79  Ibid.,  section  3501(8).  The  act  amends  chapter  35  of  title  44  U.S.C. 
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59  note),  to  identify  and  afford  security 
protections  commensurate  with  the  risk  and 
magnitude  of  the  harm  resulting  from  the 
loss,  misuse,  or  unauthorized  access  to  or 
modification  of  information  collected  or 
maintained  by  or  on  behalf  of  an  agency.80 

The  latter  requirement  for  cost-effective  security 
implementation  and  standards  is  tied  to  the  roles 
of  the  Director  of  NIST  and  the  Administrator  of 
General  Services  in  helping  the  OMB  to: 

(A)  develop  and  oversee  the  implementation  of 
polices,  principles,  standards,  and  guide¬ 
lines  for  information  technology  functions 
and  activities  of  the  Federal  Government, 
including  periodic  evaluations  of  major  in¬ 
formation  systems;  and 

(B)  oversee  the  development  and  implementa¬ 
tion  of  standards  under  section  111(d)  of  the 
Federal  Property  and  Administrative  Ser¬ 
vices  Act  of  1949  (40  U.S.C.  759(d)).81 

Federal  agency  heads  are  responsible  for  ensuring 
that  their  agencies  shall: 

1.  implement  and  enforce  applicable  policies, 
procedures,  standards,  and  guidelines  on 
privacy,  confidentiality,  security,  disclosure, 
and  sharing  of  information  collected  or 
maintained  by  or  for  the  agency; 

2.  assume  responsibility  and  accountability  for 
compliance  with  and  coordinated  manage¬ 
ment  of  sections  552  and  552a  of  title  5,  the 
Computer  Security  Act  of  1987  (40  U.S.C. 
759  note),  and  related  information  manage¬ 
ment  laws;  and 

3.  consistent  with  the  Computer  Security  Act 
of  1987  (40  U.S.C.  59  note),  identify  and  af¬ 
ford  security  protections  commensurate 
with  the  risk  and  magnitude  of  the  harm 
resulting  from  the  loss,  misuse,  or  unau¬ 
thorized  access  to  or  modification  of  in¬ 


formation  collected  or  maintained  by  or  on 
behalf  of  an  agency  82 

I  Proposed  Revision  of 
OMB  Circular  A-130  Appendix  III 

At  this  writing,  OMB  has  just  completed  the  pro¬ 
posed  revision  of  Appendix  III.  The  proposed  re¬ 
vision  is  intended  to  lead  to  improved  federal 
information-security  practices  and  to  make  fulfill¬ 
ment  of  Computer  Security  Act  and  Privacy  Act 
requirements  more  effective  generally,  as  well  as 
with  respect  to  data  sharing  and  secondary  uses. 
As  indicated  above,  the  Paperwork  Reduction  Act 
of  1995  has  affirmed  OMB’s  government- wide 
authority  for  information  security  and  privacy. 

The  new,  proposed  revision  of  Appendix  III 
(“Security  of  Federal  Automated  Information”) 
will  be  key  to  assessing  the  prospect  for  improved 
federal  information-security  practices.  The  pro¬ 
posed  revision  was  posted  for  public  comment  on 
March  29,  1995.  According  to  OMB,  the  pro¬ 
posed  new  government-wide  guidance: 

...  is  intended  to  guide  agencies  in  securing 
information  as  they  increasingly  rely  on  an  open 
and  interconnected  National  Information  Infra¬ 
structure.  It  stresses  management  controls  such 
as  individual  responsibility,  awareness  and 
training,  and  accountability,  rather  than  techni¬ 
cal  controls. 

. . .  The  proposal  would  also  better  integrate 
security  into  program  and  mission  goals,  reduce 
the  need  for  centralized  reporting  of  paper  secu¬ 
rity  plans,  emphasize  the  management  of  risk 
rather  than  its  measurement,  and  revise  govern¬ 
ment-wide  security  responsibilities  to  be  consis¬ 
tent  with  the  Computer  Security  Act.83 

According  to  OMB,  the  proposed  new  security 
guidance  reflects  the  significant  differences  in  ca- 


80  Ibid.,  section  3504(g).  The  OMB  Director  delegates  authority  to  administer  these  functions  to  the  Administrator  of  OMB’s  Office  of  In¬ 
formation  and  Regulatory  Affairs. 

81  Ibid.,  section  3504(h)(1).  See  also  “Joint  Explanatory  Statement  of  the  Committee  of  the  Conference  ”  ibid.,  pp.  27-29. 

82  Ibid.,  section  3506(g). 

83  Office  of  Management  and  Budget,  “Security  of  Federal  Automated  Information,”  Proposed  Revision  of  OMB  Circular  No.  A-130  Ap¬ 
pendix  III  (transmittal  memorandum),  available  via  World  Wide  Web  at  http://csrc.ncsl.nist.gov/secplcy  as  <al30app3.txt>. 
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pabilities,  risks,  and  vulnerabilities  of  the  present 
computing  environment,  as  opposed  to  the  rela¬ 
tively  closed,  centralized  processing  environment 
of  the  past.  Today’s  processing  environment  is 
characterized  by  open,  widely  distributed  in¬ 
formation-processing  systems  that  are  intercon¬ 
nected  with  other  systems  within  and  outside 
government  and  by  an  increasing  dependence  of 
federal  agency  operations  on  these  systems. 
OMB ’s  “federal  information  technology  world” 
encompasses  over  2  million  individual  worksta¬ 
tions  (e.g.,  PCs),  but  only  some  25,000  medium 
and  large  computers.84  Accordingly,  a  major  fo¬ 
cus  of  OMB’s  new  guidance  is  on  end  users  and 
decentralized  information-processing  systems — 
and  the  information-processing  applications  they 
use  and  support. 

According  to  OMB,  the  proposed  revision  of 
Appendix  III  stresses  management  controls  (such 
as  individual  responsibility,  awareness,  and  train¬ 
ing)  and  accountability,  rather  than  technical  con¬ 
trols.  OMB  also  considers  that  the  proposed 
security  appendix  would  better  integrate  security 
into  agencies’  program  and  mission  goals,  reduce 
the  need  for  centralized  reporting  of  paper  security 
plans,  emphasize  the  management  of  risk  rather 
than  its  measurement,  and  revise  government¬ 
wide  security  responsibilities  to  be  consistent 
with  the  Computer  Security  Act.85 

OMB’s  proposed  new  security  appendix: 

. .  .proposes  to  re-orient  the  Federal  comput¬ 
er  security  program  to  better  respond  to  a  rapidly 
changing  technological  environment.  It  estab¬ 
lishes  government-wide  responsibilities  for 
Federal  computer  security  and  requires  Federal 
agencies  to  adopt  a  minimum  set  of  manage¬ 
ment  controls. 


These  management  controls  are  directed  at 
individual  information  technology  users  in  or¬ 
der  to  reflect  the  distributed  nature  of  today’s 
technology.  For  security  to  be  most  effective, 
the  controls  must  be  a  part  of  day-to-day  opera¬ 
tions.  This  is  best  accomplished  by  planning  for 
security  not  as  a  separate  activity,  but  as  part  of 
overall  planning. 

“Adequate  security”  is  defined  as  “security 
commensurate  with  the  risk  and  magnitude  of 
harm  from  the  loss,  misuse,  or  unauthorized  ac¬ 
cess  to  or  modification  of  information.”  This 
definition  explicitly  emphasizes  the  risk-based 
policy  for  cost-effective  security  established  by 
the  Computer  Security  Act.86 

The  new  guidance  assigns  the  Security  Policy 
Board  responsibility  for  (only)  “national  security 
policy  coordination  in  accordance  with  the  ap¬ 
propriate  Presidential  directive  [e.g.,  PDD  29]. ”87 
With  respect  to  national  security  information: 

Where  an  agency  processes  information 
which  is  controlled  for  national  security  reasons 
pursuant  to  an  Executive  Order  or  statute,  secu¬ 
rity  measures  required  by  appropriate  directives 
should  be  included  in  agency  systems.  Those 
policies,  procedures,  and  practices  will  be  coor¬ 
dinated  with  the  U.S.  Security  Policy  Board  as 
directed  by  the  President.88 

Otherwise,  the  proposed  OMB  guidance  assigns 
government-wide  responsibilities  to  agencies  that 
are  “consistent  with  the  Computer  Security  Act.” 
These  include  the  Commerce  Department, 
through  NIST;  the  Defense  Department,  through 
NSA;  the  Office  of  Personnel  Management;  the 
General  Services  Administration,  and  the  Justice 
Department.89 

A  complete  analysis  of  the  proposed  revision  to 
Appendix  III  is  beyond  the  scope  of  this  back- 


84  Ed  Springer,  OMB,  personal  communication.  Mar.  23,  1995. 

85  Office  of  Management  and  Budget,  op.  cit.,  footnote  83. 

86  Ibid.,  p.  4. 

87  Ibid.,  p.  15. 

88  Ibid.,  pp.  3-4. 

89  Ibid.,  pp.  14-16. 


Chapter  4  Implications  for  Congressional  Action  1 97 


ground  paper.  In  brief,  the  proposed  new  guidance 
reflects  a  fundamental  and  necessary  shift  in  em¬ 
phasis  from  securing  automated  information  sys¬ 
tems  to  safeguarding  automated  information 
itself.  It  seeks  to  accomplish  this  through: 

■  controls  for  general  support  systems  (including 
hardware,  software,  information,  data,  applica¬ 
tions,  and  people)  that  share  common  function¬ 
ality  and  are  under  the  same  direct  management 
control;  and 

■  controls  for  major  applications  (that  require 
special  attention  due  to  their  mission-critical 
nature). 

For  each  type  of  control,  OMB  seeks  to  ensure 
managerial  accountability  by  requiring  manage¬ 
ment  officials  to  authorize  in  writing,  based  on  re¬ 
view  of  implementation  of  the  relevant  security 
plan,  use  of  the  system  or  application.  For  general 
support  systems,  OMB  specifies  that  use  should 
be  re-authorized  at  least  every  three  years.  Simi¬ 
larly,  major  applications  must  be  authorized  be¬ 
fore  operating  and  reauthorized  at  least  every  three 
years  thereafter.  For  major  applications,  manage¬ 
ment  authorization  implies  accepting  the  risk  of 
each  system  used  by  the  application.90 

This  type  of  active  risk  acceptance  and  account¬ 
ability,  coupled  with  review  and  reporting  require¬ 
ments,  is  intended  to  result  in  agencies  ensuring 
that  adequate  resources  are  devoted  to  implement¬ 
ing  “adequate  security.”  Every  three  years  (or 
when  significant  modifications  are  made),  agen¬ 
cies  must  review  security  controls  in  systems  and 
major  applications  and  correct  deficiencies.  De¬ 
pending  on  the  severity,  agencies  must  also  con¬ 
sider  identifying  a  deficiency  in  controls  pursuant 
to  the  Federal  Manager’s  Financial  Accountabil¬ 
ity  Act.  Agencies  are  required  to  include  a  sum¬ 
mary  of  their  system  security  plans  and  major 
application  security  plans  in  the  five-year  plan  re¬ 
quired  by  the  Paperwork  Reduction  Act. 


IMPLICATIONS  FOR 
CONGRESSIONAL  ACTION 

The  next  sections  discuss  implications  of  the 
above  for  congressional  actions  related  to  cryp¬ 
tography  policy  and  government  information  se¬ 
curity,  in  the  context  of  issues  and  options  OTA 
identified  in  its  1994  report  Information  Security 
and  Privacy  in  Network  Environments  (see  appen¬ 
dix  D  of  this  paper  and/or  chapter  1  of  the  1994 
report). 

I  Export  Controls  and  Standards 

Reform  of  the  current  export  controls  on  cryptog¬ 
raphy  was  certainly  the  number  one  topic  at  the 
December  1994  OTA  workshop.  More  generally, 
the  private  sector’s  priority  in  this  regard  is  indi¬ 
cated  by  the  discussion  of  the  industry  statements 
of  business  needs  above.  Legislation  would  not  be 
required  to  relax  controls  on  cryptography,  if  this 
were  done  by  revising  the  implementing  regula¬ 
tions.  However,  the  Clinton  Administration  has 
previously  evidenced  a  disinclination  to  relax 
controls  on  robust  cryptography,  except  perhaps 
for  certain  key-escrow  encryption  products.91 

The  Export  Administration  Act  is  to  be  reautho¬ 
rized  in  the  104th  Congress.  The  issue  of  export 
controls  on  cryptography  may  arise  during  con¬ 
sideration  of  export  legislation,  or  if  new  export 
procedures  for  key-escrow  encryption  products 
are  announced,  and/or  when  the  Clinton  Adminis¬ 
tration’s  market  study  of  cryptography  and  con¬ 
trols  is  completed  this  summer.  Aside  from  any 
consideration  of  whether  or  not  to  include  cryp¬ 
tography  provisions  in  the  1995  export  adminis¬ 
tration  legislation,  Congress  could  advance  the 
convergence  of  government  and  private  sector  in¬ 
terests  into  some  “feasible  middle  ground” 
through  hearings,  evaluation  of  the  Administra¬ 
tion’s  market  study,  and  by  encouraging  a  more 
timely,  open,  and  productive  dialogue  between 


90  Ibid.,  pp.  2-6. 

91  See  appendix  C,  especially  footnote  10  and  accompanying  text. 
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government  and  the  private  sector  (see  pages 
11-13, 150-160, 174-179  ofthe  1994  OTA  report.) 

Oversight  of  the  implementation  of  the  Comput¬ 
er  Security  Act  is  also  important  to  cryptography 
policy  considerations  (see  below).  The  cryptogra¬ 
phy-related  federal  information  processing  stan¬ 
dards  still  influence  the  overall  market,  and  the 
development  of  recent  FIPS  (e.g.,  the  DSS  and 
EES)  demonstrates  a  mismatch  between  the  intent 
of  the  act  and  its  implementation  by  NIST  and 
NS  A  (see  pp.  160-183  ofthe  1994  OTA  report.). 
The  attributes  of  these  standards  do  not  meet  most 
users’  needs,  and  their  deployment  would  benefit 
from  congressional  oversight,  both  in  the  strategic 
context  of  a  policy  review  and  as  tactical  response 
to  the  Clinton  Administration’s  escrowed-encryp¬ 
tion  initiative  (see  pp.  16-20  of  the  1994  OTA  re¬ 
port). 

If  the  Computer  Security  Act  is  revisited.  Con¬ 
gress  might  wish  to  redirect  NIST’s  activities 
away  from  “picking  technologies”  for  standards 
(i.e.,  away  from  developing  product-oriented 
FIPS  like  the  EES)  and  toward  providing  federal 
agencies  with  guidance  on: 

■  the  availability  of  suitable  commercial  technol¬ 
ogies; 

■  interoperability  and  application  portability; 
and 

■  how  to  make  best  use  of  existing  hardware  and 
software  technology  investments. 

Also,  targeting  NIST’s  information-security  acti¬ 
vities  toward  support  of  OMB ’s  proposed  guid¬ 
ance  (with  its  focus  on  end  users  and  individual 
workstations)  might  enable  NIST  to  be  more  ef¬ 
fective  despite  scarce  resources. 

Finally,  there  has  been  very  little  information 
from  the  Clinton  Administration  as  to  the  current 
and  projected  costs  of  the  escrowed-encryption 
initiative,  including  costs  of  the  escrow  agencies 
for  Clipper  and  Capstone  chips  and  prices  and  ex¬ 
penditures  for  the  FORTEZZA  cards.  The  latter 
may  be  indicative  of  the  likelihood  of  the 
“PCMCIA  portfolio”  FORTEZZA  approach  find¬ 
ing  favor  in  the  civil  agencies  and  in  the  private 
sector,  compared  with  more  flexible  and/or  disag¬ 


gregate  implementation  of  encryption  and  signa¬ 
ture  functions. 

I  Safeguarding  Unclassified  Information 
in  the  Federal  Agencies 

The  need  for  congressional  oversight  of  federal 
information  security  and  privacy  is  even  more 
urgent  in  a  time  of  government  reform  and  stream¬ 
lining.  When  the  role,  size,  and  structure  of  the 
federal  agencies  are  being  reexamined,  it  is  impor¬ 
tant  to  take  into  account  the  additional  infor¬ 
mation  security  and  privacy  risks  incurred  in 
downsizing  and  the  general  lack  of  commitment 
by  top  agency  management  to  safeguarding  un¬ 
classified  information. 

A  major  problem  in  the  agencies  has  been  lack  of 
top  management  focus  on,  not  to  mention  respon¬ 
sibility  and  accountability  for,  information  securi¬ 
ty.  As  the  1994  OTA  report  on  information 
security  and  privacy  in  network  environments 
noted: 

The  single  most  important  step  toward  imple¬ 
menting  proper  information  safeguards  for  net¬ 
worked  information  in  a  federal  agency  or  other 
organization  is  for  top  management  to  define  the 
organization’s  overall  objectives  and  a  security 
policy  to  reflect  those  objectives.  Only  top  man¬ 
agement  can  consolidate  the  consensus  and  ap¬ 
ply  the  resources  necessary  to  effectively 
protect  networked  information.  For  the  federal 
government,  this  means  guidance  from  OMB, 
commitment  from  top  agency  management,  and 
oversight  by  Congress,  (p.  7) 

All  too  often,  agency  managers  have  regarded 
information  security  as  “expensive  overhead”  that 
could  be  skimped  on,  deferred,  or  foregone  in  fa¬ 
vor  of  other  expenditures  (e.g.,  for  new  computer 
hardware  and  applications).  Any  lack  of  priority 
and  resources  for  safeguarding  information  is  in¬ 
creasingly  problematic  as  we  move  toward  in¬ 
creased  secondary  use  of  data,  data  sharing  across 
agencies,  and  decentralization  of  information 
processing  and  databases.  If  this  mindset  were 
permitted  to  continue  during  agency  downsizing 
and  program  consolidation,  the  potential — and 
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realized — harms  from  “disasters  waiting  to  hap¬ 
pen”  can  be  much  greater.  (See  pages  1-8,  25-31, 
and  40-43  of  the  1994  OTA  report.)  For  example, 
without  proper  attention  to  information  security, 
staffing  changes  during  agency  restructuring  and 
downsizing  can  increase  security  risks  (due  to  un¬ 
staffed  or  understaffed  security  functions,  reduc¬ 
tions  in  security  training  and  implementation, 
large  numbers  of  disgruntled  former  employees, 
etc.). 

OTA’s  ongoing  work  has  spotlighted  important 
elements  of  good  information-security  practice  in 
the  private  sector,  including  active  risk  acceptance 
by  line  management.  The  concept  of  management 
responsibility  and  accountability  as  integral  com¬ 
ponents  of  information  security,  rather  than  just 
“handing  off’  security  to  technology,  is  very  im¬ 
portant. 

Sound  security  policies  as  a  foundation  for  prac¬ 
tice  are  essential;  these  should  be  technology  neu¬ 
tral.  Technology-neutral  policies  specify  what 
must  be  done,  not  how  to  do  it.  Because  they  do 
not  prescribe  implementations,  technology-neu¬ 
tral  policies  are  longer  lived.  They  are  not  so  easi¬ 
ly  obsoleted  by  changes  in  technology  or  business 
practices;  they  allow  for  local  customization  of 
implementations  to  meet  operational  require¬ 
ments.  Once  these  are  in  place,  security  imple¬ 
mentation  should  be  audited  against  policy,  not 
against  implementation  guidelines.  This  helps 
prevent  confusing  implementation  techniques  and 
tools  (e.g.,  use  of  a  particular  type  of  encryption  or 
use  of  an  computer  operating  system  with  a  certain 
rating)  with  policy  objectives,  and  discourages 
“passive  risk  acceptance”  like  mandating  use  of  a 
particular  technology.  This  also  allows  for  flexi¬ 
bility  and  customization. 

In  the  federal  arena,  however,  more  visible  ener¬ 
gy  seems  to  be  have  been  focused  on  debates  over 
implementation  tools — that  is,  federal  informa¬ 
tion  processing  standards  like  the  Data  Encryption 
Standard,  Digital  Signature  Standard,  and  Es¬ 
crowed  Encryption  Standard — than  on  formulat¬ 
ing  enduring,  technology-neutral  policy  guidance 
for  the  agencies. 


Direction  of  Revised  OMB  Guidance 

In  the  1994  report  Information  Security  and  Pri¬ 
vacy  in  Network  Environments,  OTA  identified 
the  need  for  the  revised  version  of  the  security  ap¬ 
pendix  (Appendix  III)  of  OMB  Circular  A- 130  to 
adequately  address  problems  of  managerial  re¬ 
sponsibility  and  accountability,  insufficient  re¬ 
sources  devoted  to  information  security,  and 
overemphasis  on  technology,  as  opposed  to  man¬ 
agement.  In  particular,  OTA  noted  the  importance 
of  making  agency  line  management  (not  just  “in¬ 
formation  security  officers”)  accountable  for  in¬ 
formation  security  and  ensuring  that  privacy  and 
other  policy  objectives  are  met.  Moreover,  OTA 
noted  that  the  proposed  new  OMB  guidance 
would  have  to  provide  sufficient  incentives — es¬ 
pecially  in  times  of  budget  cuts — to  ensure  that 
agencies  devote  adequate  resources  to  safeguard¬ 
ing  information.  Similarly,  the  OMB  guidance 
would  have  to  ensure  that  information  safeguards 
are  treated  as  an  integral  component  when  systems 
are  designed  or  modified. 

The  proposed  revision  to  Appendix  III  of  OMB 
Circular  A- 130,  as  discussed  above,  shows  prom¬ 
ise  for  meeting  these  objectives.  OMB ’s  proposed 
guidance  is  intended  to  incorporate  critical  ele¬ 
ments  of  considering  security  as  integral  (rather 
than  an  add-on)  to  planning  and  operations,  active 
risk  acceptance,  line  management  responsibility 
and  accountability,  and  focus  on  management  and 
people  rather  than  technology.  Taken  as  a  whole, 
these  elements  are  intended  to  provide  sufficient 
incentives  for  agency  managements  to  devote  ade¬ 
quate  resources  to  security;  the  review  and  report¬ 
ing  requirements  offer  disincentives  for 
inadequate  security.  Moreover,  if  implemented 
properly,  the  new  OMB  approach  can  make  sig¬ 
nificant  progress  in  the  ultimate  goal  of  tracking 
and  securing  the  information  itself,  as  it  is  gath¬ 
ered,  stored,  processed,  and  shared  among  users 
and  applications. 

However,  OMB’s  twofold  approach  is  some¬ 
what  abstract  and  a  significant  departure  from  ear¬ 
lier,  “computer  security”  guidance.  Therefore, 
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congressional  review  and  oversight  of  OMB ’s 
proposed  revisions  to  Appendix  III,  as  suggested 
in  the  1994  OTA  report  (see  appendix  D  and  pages 
18-20  of  the  1994  OTA  report),  would  be  helpful 
in  ensuring  that  Congress,  as  well  as  federal  agen¬ 
cies  and  the  public,  understand  the  new  informa¬ 
tion-security  guidance  and  how  OMB  intends  for 
its  new  approach  to  be  implemented. 

This  congressional  review  and  oversight  might 
also  provide  additional  guidance  on  how  NIST’s 
security  activities  might  best  be  refocused  to  meet 
federal  information-security  objectives.  For  ex¬ 
ample,  in  addition  to  Commerce’s  (i.e.,  NIST’s) 
traditional  responsibilities  for  security  standards 
and  training  and  awareness,  the  new  Appendix  III 
assigns  Commerce  responsibilities  for  providing 
agencies  with  guidance  and  assistance  concerning 
effective  controls  when  systems  are  intercon¬ 
nected,  coordinating  incident  response  activities 
to  promote  information-sharing  regarding  inci¬ 
dents  and  related  vulnerabilities,  and  (with  De¬ 
fense  technical  assistance)  evaluating  new 
information  technologies  to  assess  their  security 
vulnerabilities  and  apprising  agencies  of  these  in  a 
timely  fashion.92 

Locus  of  Authority 

Another  reason  for  the  importance  and  timeliness 
of  congressional  oversight  of  government-wide 
information-security  policy  guidance  is  that  there 
is  momentum  for  extending  the  defense/intelli¬ 
gence  community’s  centralization  of  information- 
security  responsibilities  throughout  the  civil 
agencies  as  well.  If  initiatives  such  as  the  Informa¬ 
tion  Systems  Security  Committee  structure  pres¬ 
ented  in  the  Security  Policy  Board’s  staff  report 
come  to  fruition,  information-security  responsibi¬ 
lities  for  both  the  civilian  agencies  and  the  de¬ 
fense/intelligence  agencies  would  be  merged. 

An  overarching  issue  that  must  be  resolved  by 
Congress  is  where  federal  authority  for  safeguard¬ 
ing  unclassified  information  in  the  civilian  agen¬ 


cies  should  reside  and,  therefore,  what  needs  to  be 
done  concerning  the  substance  and  implementa¬ 
tion  of  the  Computer  Security  Act  of  1 987.  If  Con¬ 
gress  retains  the  general  premise  of  the  act — that 
responsibility  for  unclassified  information  securi¬ 
ty  in  the  civilian  agencies  should  not  be  placed 
within  the  defense/intelligene  community — then 
vigilant  oversight  and  clear  direction  will  be  need¬ 
ed  to  ensure  effective  implementation,  including 
assigning  and  funding  a  credible  focal  point  for 
unclassified  information  security  (see  discussion 
of  OMB  Appendix  III  above  and  also  pp.  19-20  of 
the  1994  OTA  report). 

Without  doubt,  leadership  and  expertise  are 
needed  for  better,  more  consistent  safeguarding  of 
unclassified  information  government-wide.  But  it 
is  not  clear  that  there  are  no  workable  alternatives 
to  centralizing  government-wide  information-se¬ 
curity  responsibilities  under  the  defense/intelli¬ 
gence  community.  Proposals  to  do  so  note  current 
information-security  deficiencies;  however, 
many  of  these  can  be  attributed  to  lack  of  commit¬ 
ment  to  and  funding  for  establishment  of  an  alter¬ 
native  source  of  expertise  and  technical  guidance 
for  the  civilian  agencies.  For  example,  the  “effi¬ 
ciency”  arguments  (see  below)  made  in  the  Joint 
Security  Commission  report  and  the  Security 
Policy  Board  staff  report  for  extending  the  respon¬ 
sibilities  of  the  defense/intelligence  community 
to  encompass  governmentwide  security  for  classi¬ 
fied  and  unclassified  information  capitalize  on  the 
vacuum  in  leadership  and  expertise  created  by 
chronic  underfunding  of  the  designated  civilian 
agency — at  present,  NIST.  (See  pp.  13-16,  20, 
138-150,  and  182-183  of  the  1994  OTA  report.) 

Proposals  for  centralizing  security  responsibili¬ 
ties  for  both  classified  and  unclassified  informa¬ 
tion  government-wide  offer  efficiency  arguments 
to  the  effect  that: 

1 .  security  policies,  practices,  and  procedures  (as 
well  as  technologies)  for  unclassified  informa- 


92  OMB,  op.  cit.,  footnote  83,  p.  7. 
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tion  are  for  the  most  part  spinoffs  from  the  clas¬ 
sified  domain; 

2.  the  defense  and  intelligence  agencies  are  expert 
in  classified  information  security;  and  there¬ 
fore 

3.  the  unclassified  domain  can  best  be  served  by 
extending  the  authority  of  the  defense/intelli¬ 
gence  agencies. 

The  validity  of  the  “spinoff’  assumption  about 
unclassified  information  security  is  questionable. 
There  are  real  questions  about  NSA’s  ability  to 
place  the  right  emphasis  on  cost-effectiveness,  as 
opposed  to  absolute  effectiveness,  in  flexibly  de¬ 
termining  the  most  appropriate  means  for  safe¬ 
guarding  unclassified  information.  Due  to  its 
primary  mission  in  securing  classified  informa¬ 
tion,  NSA’s  traditional  culture  tends  toward  a 
standard  of  absolute  effectiveness,  not  trading  off 
cost  and  effectiveness.  By  contrast,  the  Computer 
Security  Act  of  1987,  the  Paperwork  Reduction 
Act  of  1995,  and  the  new,  proposed  revision  of 
OMB  Appendix  III  all  require  agencies  to  identify 
and  employ  cost-effective  safeguards,  for  exam¬ 
ple: 

With  respect  to  privacy  and  security,  the  Di¬ 
rector  [of  OMB]  shall . . .  require  Federal  agen¬ 
cies,  consistent  with  the  Computer  Security  Act 
of  1987  (940  U.S.C.  759  note)  security  protec¬ 
tions  commensurate  with  the  risk  and  magnitude 
of  the  harm  resulting  from  the  loss,  misuse,  or 
unauthorized  access  to  or  modification  of  in¬ 
formation  collected  or  maintained  by  or  on  be¬ 
half  of  an  agency.93 

Moreover,  the  current  state  of  government  secu¬ 
rity  practice  for  unclassified  information  has  been 


depressed  by  the  chronic  shortage  of  resources  for 
NIST’s  computer  security  activities  in  fulfillment 
of  its  government-wide  responsibilities  under  the 
Computer  Security  Act  of  1987.  Since  enactment 
of  the  Computer  Security  Act,  there  has  been  no 
serious  (i.e.,  adequately  funded  and  properly 
staffed),  sustained  effort  to  establish  a  center  of  in¬ 
formation-security  expertise  and  leadership  out¬ 
side  the  defense/intelligence  communities. 

Even  if  the  efficiency  argument  is  attractive, 
Congress  would  still  need  to  consider  whether  the 
gains  would  be  sufficient  to  overcome  the  con¬ 
comitant  decrease  in  “openness”  in  information- 
security  policymaking  and  implementation, 
and/or  whether  the  outcomes  would  fall  at  an  ac¬ 
ceptable  point  along  the  “efficiency-openness” 
possibility  frontier.  In  the  area  of  export  controls 
on  cryptography,  for  example,  there  is  substantial 
public  concern  with  the  current  tradeoff  between 
the  needs  of  the  defense/intelligence  and  the  busi¬ 
ness/user  communities.  With  respect  to  informa¬ 
tion-security  standards  and  guidelines,  there  has 
been  continuing  concern  with  the  lack  of  openness 
and  accountability  in  policies  formulated  and  im¬ 
plemented  under  executive  order,  rather  than 
through  the  legislative  process.  It  would  be  diffi¬ 
cult  to  formulate  a  scenario  in  which  increasing 
the  defense/intelligence  community’s  authority 
government-wide  would  result  in  more  openness 
or  assuage  public  concerns.  (In  the  1980s,  con¬ 
cerns  over  NSDD-145’s  placement  of  govern¬ 
mental  authority  for  unclassified  information 
security  within  the  defense/intelligence  commu¬ 
nity  led  to  enactment  of  the  Computer  Security 
Act  of  1987.) 


93  “Paperwork  Reduction  Act  of  1995”  (S.  244),  section  3504(g)(3),  Mar.  7,  1995,  Federal  Record ,  p.  S3557. 
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COMMITTEE  ON 

GOVERNMENTAL  AFFAIRS  _ 


Washington,  oc  20510-6250 
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ur.  H'TTnro’r  «r 

Director  _ 

Office  of  Technology  Assessment 
United  States  Congress 

n  H  20510  9025 

Dear  Dr.  Herdman: 


Thank  you  again  for  the  fine  report,  Information 
security  aria  privacy  in  Network  Environments.  As  you  may 
recall,  that  report  was  prepared  in  response  to  our  interest 
in  how  government  policies  must  adapt  to  changes  in 
communications  network  technologies  that  affect  the  privacy 
and  economic  livelihood  of  every  American.  The  report 
highlights  key  issues  and  makes  recommendations  that  should 
serve  as  the  basis  for  hearings  and  legislation.  Towards  that 
end,  we  are  Writing  to  ask  for  your  assistance  in  working  with 
our  staff  to  .follow-up  and  develop  ^further  the  findings  of  the 
report »  _ : _ _  _  — - 


We  would  appreciate  it  if  the  project  director,  Ms. 
*”*  - 1  staff  and  rs scurces  to- 


assist  our  staff  in  preparing  for  hearings  and  subsequent 
legis lotion .  In  particular,  we  request  analytical  support  on 
policy  requirements  and  alternatives,  including  further 
insights  in  computer  network  security  problems  -that— affect  ths 
survivability  and  reliability  of  such  networks.  In  addition, 
the  Committee  needs  information  gathered  from  industry, 
“Government-  agenc les <mu  utrinr  sources  in  response 


agnao 


raised  in  the  report,  including  relevant  implications  of. 
emerging  technology.  In  carrying  out  this  request,  we  would 
also  like  the  Office  of  Technology  Assessment  to  host  a 
meeting  with  renrpgpni’Rtivog  of  government-  *nd 

academia  to  discuss  the  findings  of  the  report. 


J-I-C  VJX  j.  ECTTTfrn 
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underscores  the  fact  that  much  more  work  must  be  done.  There 
are  many  questions  aoout  the  role  of  government  that  the 
Governmental  Affairs  Committee  must  address.  We  would 
appreciate  your  continued  cooperation. 


Sincerely, 


William  V.  Roth,  -Jr« - 

Ranking  Republican  Member 


Appendix  B : 
Federal  Information 
Security  and  the 
Computer  Security  Act 


This  appendix  draws  on  chapter  4  of  the 
September  1994  OTA  report  Information 
Security  and  Privacy  in  Network  Environ¬ 
ments , 1  with  updates  as  noted  herein.  That 
chapter  of  the  1994  report  examined  the  policy 
framework  within  which  federal  agencies  formu¬ 
late  and  implement  their  information-security  and 
privacy  policies  and  guidelines.  Because  of  its  im¬ 
portance  for  federal  government  information  se¬ 
curity  and  cryptography  policy,  the  Computer 
Security  Act  of  1987  (Public  Law  100-235)  was 
examined  in  detail. 

The  Computer  Security  Act  of  1987  estab¬ 
lished  a  federal  government  computer-security 
program  that  would  protect  sensitive  information 
in  federal  government  computer  systems  and 
would  develop  standards  and  guidelines  for  un¬ 
classified  federal  computer  systems  to  facilitate 
such  protection.  Specifically,  the  Computer  Secu¬ 
rity  Act  assigned  responsibility  for  developing 
government-wide,  computer-system  security 
standards  and  guidelines  and  security-training 
programs  to  the  National  Bureau  of  Standards 
(now  the  National  Institute  of  Standards  and 


Technology,  or  NIST).  The  act  also  established  a 
Computer  System  Security  and  Privacy  Advisory 
Board  within  the  Commerce  Department.  Addi¬ 
tionally,  the  act  required  federal  agencies  to  iden¬ 
tify  computer  systems  containing  sensitive 
information,  to  develop  security  plans  for  identi¬ 
fied  systems,  and  to  provide  periodic  training  in 
computer  security  for  all  federal  employees  and 
contractors  who  manage,  use,  or  operate  federal 
computer  systems. 

In  Information  Security  and  Privacy  in  Net¬ 
work  Environments ,  OTA  found  that  implementa¬ 
tion  of  the  Computer  Security  Act  has  been 
problematic  (see  chapter  4  of  the  1994  report).  In 
workshop  discussions  and  interviews  during  and 
after  the  assessment,  OTA  found  strong  sentiment 
that  agencies  follow  the  rules  set  forth  by  the  act 
regarding  security  plans  and  training,  but  do  not 
necessarily  fulfill  the  intent  of  the  act.  For  exam¬ 
ple,  agencies  are  required  to  develop  security 
plans — and  do — but  may  not  “do  the  plan”  or  up¬ 
date  plans  and  implementation  in  a  timely  fashion 
to  reflect  changes  in  technology  or  operations  (see 
section  on  implementation  issues  below). 


1  U.S.  Congress,  Office  of  Technology  Assessment,  Information  Security  and  Privacy  in  Network  Environments,  OTA-TCT-606  (Washing¬ 
ton,  DC:  U.S.  Government  Printing  Office,  September  1994). 
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Implementation  of  the  Computer  Security  Act 
has  been  especially  controversial  regarding  the 
roles  of  NIST  and  National  Security  Agency 
(NSA)  in  standards  development  for  unclassified 
federal  computer  systems.  The  act  was  designed 
to  balance  national  security  and  other  national  ob¬ 
jectives,  giving  what  is  now  the  National  Institute 
of  Standards  and  Technology  the  lead  in  develop¬ 
ing  security  standards  and  guidelines  and  defining 
the  role  of  NSA  as  technical  advisor  to  NIST.2 
However,  events  subsequent  to  the  act  have  not 
convincingly  demonstrated  NIST’s  leadership  in 
this  area.  In  OTA’s  view,  NSA  has  enjoyed  de  fac¬ 
to  leadership  in  the  development  of  cryptographic 
standards  and  technical  guidelines  for  unclassi¬ 
fied  information  security,  and  implementation  of 
the  act  has  not  fulfilled  congressional  intent  in  this 
respect.3 

EVOLUTION  OF  POLICY  FRAMEWORK 
FOR  UNCLASSIFIED  INFORMATION 
SECURITY4 

Statutory  guidance  on  safeguarding  information 
provides  a  policy  framework — in  terms  of  techni¬ 
cal  and  institutional  requirements  and  managerial 
responsibilities — for  government  information 
and  information-system  security.  Overlaid  on  this 
are  statutory  privacy  requirements  that  set  forth 
policies  concerning  the  dissemination  and  use  of 
certain  types  of  information  about  individuals. 
Within  this  framework,  and  subject  to  their  own 
specific  statutory  requirements,  federal  agencies 
and  departments  develop  their  policies  and  guide¬ 
lines,  in  order  to  meet  individual  and  government- 
wide  security  and  privacy  objectives. 


The  Privacy  Act  of  1974  (Public  Law  93-579) 
set  forth  data  collection,  confidentiality,  proce¬ 
dural,  and  accountability  requirements  federal 
agencies  must  meet  to  prevent  unlawful  invasions 
of  personal  privacy,  and  provides  remedies  for 
noncompliance.  It  does  not  mandate  use  of  specif¬ 
ic  technological  measures  to  accomplish  these  re¬ 
quirements.  Other  statutes  set  forth  information 
confidentiality  and  integrity  requirements  for  spe¬ 
cific  agencies,  such  as  the  Internal  Revenue  Ser¬ 
vice,  Bureau  of  the  Census,  and  so  forth.  (Issues 
related  to  the  Privacy  Act,  and  other,  international 
privacy  issues  are  discussed  in  chapter  3  of  the 
1994  OTA  report.) 

The  Brooks  Act  of  1965  (Public  Law  89-306) 
was  enacted  to  “provide  for  the  economic  and  effi¬ 
cient  purchase,  lease,  maintenance,  operation,  and 
utilization  of  automatic  data  processing  [ADP] 
equipment  by  federal  departments  and  agencies.” 
[OTA  note:  New  procurement  legislation  in  the 
104th  Congress  may  supersede  the  Brooks  Act.] 
The  Warner  Amendment  (Public  Law  97-86)  sub¬ 
sequently  exempted  certain  types  of  Defense  De¬ 
partment  procurements  from  the  Brooks  Act  (and 
from  section  1 1 1  of  the  Federal  Property  and  Ad¬ 
ministrative  Services  Act  of  1949). 

Among  other  provisions,  the  Brooks  Act  made 
the  Commerce  Department  the  focal  point  for  pro¬ 
mulgation  of  government  “automatic  data  proc¬ 
essing”  (i.e.,  computer  and  information-system) 
standards  and  authorized  Commerce  to  conduct  a 
research  program  to  support  standards  develop¬ 
ment  and  assist  federal  agencies  in  implementing 
these  standards.  These  responsibilities  were  car- 


2  NIST  recommends  standards  and  guidelines  to  the  Secretary  of  Commerce  for  promulgation.  Such  standards  and  guidelines  would  apply 
to  federal  computer  systems,  except  for:  1)  those  systems  excluded  by  section  2315  of  Title  10,  USC  or  section  3502(2)  of  Title  44,  USC;  and  2) 
those  systems  protected  at  all  times  by  procedures  established  for  information  classified  by  statute  or  executive  order  (Public  Law  100-235, 
section  3).  The  first,  “Warner  Amendment,”  exclusion  pertains,  for  example,  to  intelligence  or  national  security  cryptologic  systems,  mission- 
critical  military  or  intelligence  systems,  or  systems  involving  the  direct  command  and  control  of  military  forces. 

3  See  OTA,  op.  cit.,  footnote  1,  pp.  138-148, 182-184.  See  also  U.S.  General  Accounting  Office,  Communications  Privacy:  Federal  Policy 
and  Actions,  GAO/OSI-94-2  (Washington,  DC:  U.S.  Government  Printing  Office,  November  1993). 

4  This  is  taken  from  OTA,  op.  cit.,  footnote  1,  ch.  4,  esp.  pp.  132-138. 
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ried  out  by  the  National  Bureau  of  Standards  (now 
NIST). 

NBS  established  its  program  in  computer  and 
communications  security  in  1973,  under  authority 
of  the  Brooks  Act;  the  agency  was  already  devel¬ 
oping  performance  standards  for  government 
computers.  This  security  program  led  to  the  adop¬ 
tion  of  the  Data  Encryption  Standard  (DES)  as  a 
federal  information  processing  standard  (FIPS) 
for  use  in  safeguarding  unclassified  information. 
The  security  responsibilities  of  what  is  now 
NIST’s  Computer  Systems  Laboratory  (CSL) 
were  affirmed  and  extended  by  the  Computer  Se¬ 
curity  Act  of  1987. 

The  Paperwork  Reduction  Act  of  1980  (Pub¬ 
lic  Law  96-5 11)  gave  agencies  a  broad  mandate  to 
perform  their  information-management  activities 
in  an  efficient,  effective,  and  economical  manner. 
[OTA  note :  The  Paperwork  Reduction  Act  of  1995 
was  reported  on  April  3,  1995 ,  and  was  cleared 
for  the  White  House  on  April  6,  1995.  The  1995 
legislation  is  discussed  in  chapter  4  of  this  back¬ 
ground  paper.  The  historical  discussion  below  re¬ 
fers  to  the  1980  law.] 

The  Paperwork  Reduction  Act  of  1980  as¬ 
signed  the  Office  of  Management  and  Budget 
(OMB)  responsibilities  for  maintaining  a  compre¬ 
hensive  set  of  information  resources  management 
policies  and  for  promoting  the  use  of  information 
technology  to  improve  the  use  and  dissemination 
of  information  by  federal  agencies.  OMB  was  giv¬ 
en  authority  for  the  following:  developing  and  im¬ 
plementing  uniform  and  consistent  information 
resource  management  policies;  overseeing  the  de¬ 
velopment  of  and  promoting  the  use  of  gov¬ 
ernment  information  management  principles, 
standards,  and  guidelines;  evaluating  the  adequa¬ 
cy  and  efficiency  of  agency  information  manage¬ 
ment  practices;  and  determining  whether  these 
practices  comply  with  the  policies,  principles, 
standards,  and  guidelines  promulgated  by  the  di¬ 
rector  of  OMB. 

OMB  Circular  A-130  (“Management  of  Fed¬ 
eral  Information  Resources”)  was  originally  is¬ 
sued  in  1985  to  fulfill  these  and  other  statutory 
requirements  (including  the  Privacy  Act).  Circu¬ 
lar  A-130  revised  and  consolidated  policies  and 


procedures  from  several  other  OMB  directives, 
which  were  rescinded.  OMB  Circular  A-130  has 
recently  been  revised.  The  first  stage  of  revisions 
(June  1993)  focused  on  information  exchanges 
with  the  public;  the  second  stage  addressed 
agency  management  practices  for  information 
technology  and  information  systems  (July  1994). 
The  third  stage,  addressing  security  controls  and 
responsibilities  in  Appendix  III  of  the  circular,  is 
ongoing  at  this  writing. 

[OTA  note:  The  historical  overview  of  policy 
development  below  refers  to  the  1985  version  of 
Appendix  III.  OMB’s  1995  proposed  revision  of 
Appendix  III  is  discussed  in  chapter  4  of  this  back¬ 
ground  paper.  ] 

Appendix  III  of  OMB  Circular  A-130  (1985) 
addressed  the  “Security  of  Federal  Automated  In¬ 
formation  Systems.”  Its  purpose  was  to  establish  a 
minimal  set  of  controls  to  be  included  in  federal 
information  systems  security  programs,  assign  re¬ 
sponsibilities  for  the  security  of  agency  informa¬ 
tion  systems,  and  clarify  the  relationship  between 
these  agency  controls  and  security  programs  and 
the  requirements  of  OMB  Circular  A- 123  (“Inter¬ 
nal  Control  Systems”).  The  1985  appendix  also 
incorporated  responsibilities  from  applicable  na¬ 
tional  security  directives. 

Section  4(a)  of  the  1985  version  of  the  security 
appendix  of  OMB  Circular  A-130  assigned  the 
Commerce  Department  responsibility  for: 

1.  developing  and  issuing  standards  and  guide¬ 
lines  for  assuring  the  security  of  federal  in¬ 
formation  systems; 

2.  establishing  standards  “approved  in  accor¬ 
dance  with  applicable  national  security  direc¬ 
tives,”  for  systems  used  to  process  “sensitive” 
information,  “the  loss  of  which  could  adversely 
affect  the  national  security  interest;”  and 

3.  providing  technical  support  to  agencies  in  im¬ 
plementing  Commerce  Department  standards 
and  guidelines. 

According  to  the  1985  Appendix  III,  the  Defense 
Department  was  to  act  as  the  executive  agent  of 
the  government  for  the  security  of  telecommu¬ 
nications  and  information  systems  that  process  in¬ 
formation,  “the  loss  of  which  could  adversely 
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affect  the  national  security  interest”  (i.e.,  includ¬ 
ing  information  that  was  unclassified  but  was  con¬ 
sidered  “sensitive”),  and  was  to  provide  technical 
material  and  assistance  to  federal  agencies  con¬ 
cerning  the  security  of  telecommunications  and 
information  systems. 

These  responsibilities  later  shifted  (see  below) 
in  accordance  with  the  Computer  Security  Act  of 
1987  and  the  subsequent  National  Security  Direc¬ 
tive  42  (NSD  42).  After  the  Computer  Security 
Act  was  enacted,  NSD  42  set  the  leadership  re¬ 
sponsibilities  of  the  Commerce  and  Defense  De¬ 
partments  according  to  whether  the  information 
domain  was  outside  or  within  the  area  of  “national 
security.”5 

The  Computer  Security  Act  of  1987  (Public 
Law  100-235)  affirmed  and  expanded  the  comput¬ 
er-security  research  and  standards  responsibilities 
of  NBS  (now  NIST)  and  gave  it  the  responsibility 
for  developing  computer  system  security  training 
programs  and  for  commenting  on  agency  comput¬ 
er  system  security  plans.  The  Computer  Security 
Act  is  particularly  important  because  it  is  funda¬ 
mental  to  the  development  of  federal  standards  for 
safeguarding  unclassified  information,  to  the  bal¬ 
ance  between  national  security  and  other  objec¬ 
tives  in  implementing  security  and  privacy 
policies  within  the  federal  government,  and  to  is¬ 
sues  concerning  government  control  of  cryptogra¬ 


phy.  Moreover,  review  of  the  controversies  and 
debate  surrounding  the  Computer  Security  Act — 
and  subsequent  controversies  over  its  implemen¬ 
tation — provides  background  for  understanding 
current  issues. 

THE  COMPUTER  SECURITY  ACT6 

The  Computer  Security  Act  of  1987  (Public  Law 
100-235)7  was  a  legislative  response  to  overlap¬ 
ping  responsibilities  for  computer  security  among 
several  federal  agencies,  heightened  awareness  of 
computer  security  issues,  and  concern  over  how 
best  to  control  information  in  computerized  or 
networked  form.  As  noted  above,  the  act  estab¬ 
lished  a  federal  government  computer-security 
program  that  would  protect  sensitive  information 
in  federal  government  computer  systems  and 
would  develop  standards  and  guidelines  for  un¬ 
classified  federal  computer  systems  to  facilitate 
such  protection.8  Additionally,  the  act  required 
federal  agencies  to  identify  computer  systems 
containing  sensitive  information,  to  develop  secu¬ 
rity  plans  for  identified  systems,  and  to  provide 
periodic  training  in  computer  security  for  all  fed¬ 
eral  employees  and  contractors  who  manage,  use, 
or  operate  federal  computer  systems.  The  act  also 
established  a  Computer  System  Security  and  Pri¬ 
vacy  Advisory  Board  within  the  Commerce  De- 


5  The  Computer  Security  Act  of  1987  gave  the  Commerce  Department  responsibility  in  information  domains  that  contained  information 
that  was  “sensitive”  but  not  classified  for  national  security  purposes.  National  Security  Directive  42  (National  Policy  for  the  Security  ofNation- 
al  Security  femphasis  added]  Telecommunications  and  Information  Systems ,  July  5, 1990)  established  a  National  Security  Telecommunications 
and  Information  Systems  Security  Committee  (NSTISSC),  made  the  Secretary  of  Defense  the  Executive  Agent  of  the  Government  for  National 
Security  Telecommunications  and  Information  Systems,  and  designated  the  Director  of  NSA  as  the  National  Manager  for  National  Security 
Telecommunications  and  Information  Systems.  [ OTA  note:  This  information-security  structure  may  be  superseded  by  a  new  structure  under  the 
Security  Policy  Board,  wherein  NSTISSC ’s  functions  would  be  incorporated  into  the  functions  of  a  new  Information  Systems  Security  Commit¬ 
tee.  See  chapter  4  and  box  1-3  of  this  paper  for  discussion  of  the  Security  Policy  Board.] 

6  This  is  taken  from  OTA,  op.  cit.,  footnote  1,  ch.  4.  See  pp.  140-142  of  that  report  for  legislative  history  of  the  Computer  Security  Act. 

7  101  Stat.  1724. 

8  The  act  was  “[t]o  provide  for  a  computer  standards  program  within  the  National  Bureau  of  Standards,  to  provide  for  government- wide 
computer  security,  and  to  provide  for  the  training  in  security  matters  of  persons  who  are  involved  in  the  management,  operation,  and  use  of 
federal  computer  systems,  and  for  other  purposes”  (ibid.).  Specifically,  the  Computer  Security  Act  assigned  responsibility  for  developing  gov¬ 
ernment-wide,  computer-system  security  standards  and  guidelines  and  security-training  programs  to  the  National  Bureau  of  Standards  (now 
the  National  Institute  of  Standards  and  Technology).  NBS  (now  NIST)  would  recommend  these  to  the  Secretary  of  Commerce  for  promulga¬ 
tion. 
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partment.  (The  Computer  Security  Act  and  a 
controversial  1989  Memorandum  of  Understand¬ 
ing  (MOU)  laying  out  the  working  relationship 
between  NIST  and  NSA  to  implement  the  act  are 
contained  in  appendix  B  of  the  1994  OTA  report). 

Congressional  concerns  and  public  awareness 
created  a  climate  conducive  to  passage  of  the 
Computer  Security  Act  of  1987.  Highly  publi¬ 
cized  incidents  of  unauthorized  users,  or  “hack¬ 
ers,”  gaining  access  to  computer  systems  and  a 
growing  realization  of  the  government’s  depen¬ 
dence  on  information  technologies  renewed  na¬ 
tional  interest  in  computer  security  in  the  early 
1980s.9 

Disputes  over  how  to  control  unclassified  in¬ 
formation  also  prompted  passage  of  the  act.  The 
Reagan  Administration  had  sought  to  give  the  Na¬ 
tional  Security  Agency  much  control  over  what 
was  termed  “sensitive,  but  unclassified”  informa¬ 
tion,  while  the  public — especially  the  academic, 
banking,  and  business  communities — viewed 
NSA  as  an  inappropriate  agency  for  such  respon¬ 
sibility.  The  Reagan  Administration  favored  an 
expanded  concept  of  national  security.10  This  ex¬ 
panded  concept  was  embodied  in  subsequent 
presidential  policy  directives  (see  below),  which 
in  turn  expanded  NS  A’s  control  over  computer  se¬ 
curity.  Questions  regarding  the  role  of  NSA  in  se¬ 
curity  for  unclassified  information,  the  types  of 
information  requiring  protection,  and  the  general 
amount  of  security  needed,  all  divided  the  Reagan 


Administration  and  the  scientific  community  in 
the  1980s.11 

I  Agency  Responsibilities  Before  the  Act 

Some  level  of  federal  computer- security  responsi¬ 
bility  rests  with  the  Office  of  Management  and 
Budget,  the  General  Services  Administration 
(GSA),  and  the  Commerce  Department  (specifi¬ 
cally  NIST  and  the  National  Telecommunications 
and  Information  Administration  (NTIA)).  OMB 
maintains  overall  responsibility  for  computer  se¬ 
curity  policy. 12  GSA  issues  regulations  for  physi¬ 
cal  security  of  computer  facilities  and  oversees 
technological  and  fiscal  specifications  for  security 
hardware  and  software.13  In  addition  to  its  other 
responsibilities,  NSA  traditionally  has  been  re¬ 
sponsible  for  security  of  information  that  is  classi¬ 
fied  for  national  security  purposes,  including 
Defense  Department  information.14  Under  the 
Brooks  Act,  Commerce  develops  the  federal  in¬ 
formation  processing  standards  that  provide 
specific  codes,  languages,  procedures,  and  tech¬ 
niques  for  use  by  federal  information  systems 
managers.15  NTIA  serves  as  the  executive  branch 
developer  of  federal  telecommunications 
policy.16 

These  overlapping  agency  responsibilities  hin¬ 
dered  the  development  of  one  uniform  federal 
policy  regarding  the  security  of  unclassified  in¬ 
formation,  particularly  because  computer  security 


9  U.S.  Congress,  Office  of  Technology  Assessment,  Federal  Government  Information  Technology:  Management,  Security  and  Congres¬ 
sional  Oversight,  OTA-CIT-297  (Washington,  DC:  U.S.  Government  Printing  Office,  February  1986),  pp.  64-65. 

10  See,  e.g.,  Harold  Relyea,  Silencing  Science:  National  Security  Controls  and  Scientific  Communication  (Norwood,  NJ:  Ablex,  1994). 

1 1  See,  e.g.,  John  T.  Soma  and  Elizabeth  J.  Bedient,  “Computer  Security  and  the  Protection  of  Sensitive  but  Not  Classified  Data:  The  Com¬ 
puter  Security  Act  of  1987,”  Air  Force  Law  Review,  vol.  30,  1989,  p.  135. 

12  U.S.  Congress,  House  of  Representatives,  Committee  on  Science,  Space,  and  Technology,  Computer  Security  Act  of  1987—Report  to 
Accompany  H.R.  745,H.Rept.  100-153,  Parti,  100th  Cong.,  1st  sess.,  June  11, 1987  (Washington,  DC:  U.S.  Government  Printing  Office,  1987), 
p.  7. 

13  Ibid. 

14  Ibid. 

15  Ibid.  The  FIPS  apply  to  federal  agencies,  but  some,  like  the  DES,  have  been  adopted  in  voluntary,  industry  standards  and  are  used  in  the 
private  sector.  The  FIPS  are  developed  by  NIST  and  approved  by  the  Secretary  of  Commerce. 

16  Ibid. 
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and  communications  security  historically  have 
developed  separately.  In  1978,  OMB  had  issued 
Transmittal  Memorandum  No.  1  (TM-1)  to  its 
Circular  A-71,  which  addressed  the  management 
of  federal  information  technology.17  TM-1  re¬ 
quired  federal  agencies  to  implement  computer 
security  programs,  but  a  1982  General  Account¬ 
ing  Office  (GAO)  report  concluded  that  Circular 
A-71  (and  its  TM-1)  had  failed  to  provide  clear 
guidance.18 

Executive  orders  in  the  1980s,  specifically  the 
September  1984  National  Security  Decision  Di¬ 
rective  145,  “National  Policy  on  Telecommu¬ 
nications  and  Automated  Information  Systems 
Security”  (NSDD-145),19  created  significant 
shifts  and  overlaps  in  agency  responsibilities.  Re¬ 
solving  these  was  an  important  objective  of  the 
Computer  Security  Act.  NSDD-145  addressed 
safeguards  for  federal  systems  that  process  or 
communicate  unclassified,  but  “sensitive”  in¬ 
formation.  NSDD-145  established  a  Systems  Se¬ 
curity  Steering  Group  to  oversee  the  directive  and 
its  implementation,  and  an  interagency  National 
Telecommunications  and  Information  Systems 
Security  Committee  (NTISSC)  to  guide  imple¬ 
mentation  under  the  direction  of  the  steering 
group.20 

I  Expanded  NSA  Responsibilities 
Under  NSDD-145 

In  1980,  Executive  Order  12333  had  designated 
the  Secretary  of  Defense  as  Executive  Agent  of  the 
Government  for  Communications  Security. 
NSDD-145  expanded  this  role  to  encompass  tele¬ 
communications  and  information  systems  securi¬ 
ty  and  responsibility  for  implementing  policies 


developed  by  NTISSC.  The  Director  of  NSA  was 
designated  National  Manager  for  Telecommu¬ 
nications  and  Automated  Information  Systems 
Security.  The  national  manager  was  to  implement 
the  Secretary  of  Defense’s  responsibilities  under 
NSDD-145.  As  a  result,  NSA  was  charged  with 
examining  government  information  and  telecom¬ 
munications  systems  to  evaluate  their  vulnerabili¬ 
ties,  as  well  as  with  reviewing  and  approving  all 
standards,  techniques,  systems,  and  equipment 
for  telecommunications  and  information  systems 
security. 

In  1985,  the  Office  of  Management  and  Budget 
issued  another  circular  concerning  computer  se¬ 
curity.  This  OMB  Circular  A- 130,  “Management 
of  Federal  Information  Resources,”  revised  and 
superseded  Circular  A-71  (see  previous  section). 
OMB  Circular  A- 130  defined  security,  encour¬ 
aged  agencies  to  consider  information  security  es¬ 
sential  to  internal  control  reviews,  and  clarified 
the  definition  of  “sensitive”  information  to  in¬ 
clude  information  “whose  improper  use  or  disclo¬ 
sure  could  adversely  affect  the  ability  of  an  agency 
to  accomplish  its  mission  . . .  .”21 

In  1986,  presidential  National  Security  Adviser 
John  Poindexter22  issued  “National  Telecommu¬ 
nications  and  Information  Systems  Security 
Policy  Directive  No.  2”  (NTISSP  No.  2).  NTISSP 
No.  2  proposed  a  new  definition  of  “sensitive  but 
unclassified  information.”  It  potentially  could 
have  restricted  access  to  information  that  pre¬ 
viously  had  been  available  to  the  public.  Specifi¬ 
cally,  “sensitive  but  unclassified  information,” 
within  the  meaning  set  forth  in  the  directive,  in¬ 
cluded  not  only  information  which,  if  revealed, 
could  adversely  affect  national  security,  but  also 


17  Office  of  Management  and  Budget,  Transmittal  Memorandum  No.  1  to  OMB  Circular  A-71,  1978. 

18  U.S.  General  Accounting  Office,  Federal  Information  Systems  Remain  Highly  Vulnerable  to  Fraudulent,  Wasteful,  Abusive,  and  Illegal 
Practices  (Washington,  DC:  U.S.  Government  Printing  Office,  1982). 

19  NSDD-145  is  classified.  An  unclassified  version  was  used  as  the  basis  for  this  discussion. 

20  This  became  the  National  Security  Telecommunications  and  Information  Systems  Security  Committee,  or  NSTISSC.  See  footnote  5. 

21  Office  of  Management  and  Budget,  OMB  Circular  A- 130  (1985).  At  this  writing,  the  proposed  revision  of  Appendix  III  of  A- 130  had  just 
been  published.  The  main  section  of  A- 130  was  revised  and  issued  in  1993. 

22  Adm.  Poindexter  was  also  chairman  of  the  NSDD-145  Systems  Security  Steering  Group  (NSDD-145,  sec.  4). 
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information  that  could  adversely  affect  “other  fed¬ 
eral  government  interests”  if  released.  Other  fed¬ 
eral  government  interests  included  economic, 
financial,  technological,  industrial,  agricultural, 
and  law  enforcement  interests. 

Such  an  inclusive  directive  sparked  enormous, 
negative  public  response.  As  the  Deputy  Director 
of  NBS  stated  during  1987  hearings  on  the  Com¬ 
puter  Security  Act,  the  NTISSP  No.  2  definition 
of  sensitive  information  was  a  “totally  inclusiona¬ 
ry  definition. . .  [t]here  is  no  data  that  anyone 
would  spend  money  on  that  is  not  covered  by  that 
definition.”23  Opponents  of  NSDD-145  and 
NTISSP  No.  2  argued  that  NSA  should  not  have 
control  over  federal  computer  security  systems 
that  did  not  contain  classified  information  24  The 
business  community,  in  particular,  expressed  con¬ 
cern  about  NSA’s  ability  and  suitability  to  meet 
the  private  sector’s  needs  and  hesitated  to  adopt 
NSA’s  cryptographic  technology  in  lieu  of  the 
DES.  At  the  time,  the  DES  was  up  for  recertifica¬ 
tion.25  In  the  House  Report  accompanying  H.R. 
145,  the  Committee  on  Science,  Space  and 
Technology  noted  that: 

NSDD-145  can  be  interpreted  to  give  the  na¬ 
tional  security  community  too  great  a  role  in  set¬ 
ting  computer  security  standards  for  civil 
agencies.  Although  the  [Reagan]  Administra¬ 
tion  has  indicated  its  intention  to  address  this  is¬ 
sue,  the  Committee  felt  it  is  important  to  pursue 
a  legislative  remedy  to  establish  a  civilian  au¬ 
thority  to  develop  standards  relating  to  sensi¬ 
tive,  but  unclassified  data  26 


In  its  explanation  of  the  bill,  the  committee  also 
noted  that: 

One  reason  for  the  assignment  of  responsibil¬ 
ity  to  NBS  for  developing  federal  computer  sys¬ 
tem  security  standards  and  guidelines  for 
sensitive  information  derives  from  the  commit¬ 
tee’s  concern  about  the  implementation  of  Na¬ 
tional  Security  Decision  Directive- 145. 

. . .  While  supporting  the  need  for  a  focal 
point  to  deal  with  the  government  computer  se¬ 
curity  problem,  the  Committee  is  concerned 
about  the  perception  that  the  NTISSC  favors 
military  and  intelligence  agencies.  It  is  also  con¬ 
cerned  about  how  broadly  NTISSC  might  inter¬ 
pret  its  authority  over  “other  sensitive  national 
security  information.”  For  this  reason,  H.R.  145 
creates  a  civilian  counterpart,  within  NBS,  for 
setting  policy  with  regard  to  unclassified  in¬ 
formation.  .  .  NBS  is  required  to  work  closely 
with  other  agencies  and  institutions  such  as 
NSA,  both  to  avoid  duplication  and  to  assure 
that  its  standards  and  guidelines  are  consistent 
and  compatible  with  standards  and  guidelines 
developed  for  classified  systems;  but  the  final 
authority  for  developing  the  standards  and 
guidelines  for  sensitive  information  rests  with 
the  NBS.27 

In  its  report  on  H.R.  145,  the  Committee  on 
Government  Operations  explicitly  noted  that  the 
bill  was  “neutral”  with  respect  to  public  disclosure 
of  information  and  was  not  to  be  used  by  agencies 
to  exercise  control  over  privately  owned  informa¬ 
tion,  public  domain  information,  or  information 


23  Raymond  Kammer,  Deputy  Director,  National  Bureau  of  Standards,  testimony,  “Computer  Security  Act  of 1987:  Hearings  on  HR.  145 
Before  the  Subcommittee  on  Legislation  and  National  Security  of  the  House  Committee  on  Government  Operations ,”  100th  Cong.,  1st  Sess., 
Feb.  26,  1987.  See  also  H.  Rept.  100-153,  Part  I,  op.  cit.,  footnote  12,  p.  18. 

24  See  U.S.  Congress,  House  of  Representatives,  Committee  on  Science,  Space  and  Technology,  Computer  Security  Act  of 1987:  Hearings 
on  HR.  145  Before  the  Subcommittee  on  Science,  Research,  and  Technology  and  the  Subcommittee  on  Transportation,  Aviation,  and  Materials 
of  the  House  Committee  on  Science,  Space,  and  Technology,  100th  Cong.,  1st  sess.  (Washington,  DC:  U.S.  Government  Printing  Office,  1987), 
pp.  146-191. 

25  Despite  NSA’s  desire  to  replace  the  DES  with  a  family  of  tamper  proof  cryptographic  modules  using  classified  algorithms,  the  DES  was 
reaffirmed  in  1988. 

26  H.  Rept.  100-153,  Part  I,  op.  cit.,  footnote  12,  p.  22. 

27  Ibid.,  p.  26. 
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disclosable  under  the  Freedom  of  Information  Act 
or  other  laws.28  Furthermore,  the  committee 
noted  that  H.R.  145  was  developed  in  large  part  to 
ensure  the  delicate  balance  between  “the  need  to 
protect  national  security  and  the  need  to  pursue  the 
promise  that  the  intellectual  genius  of  America  of¬ 
fers  us.”  29  The  committee  also  noted  that: 

Since  it  is  a  natural  tendency  of  DOD  to  re¬ 
strict  access  to  information  through  the  classifi¬ 
cation  process,  it  would  be  almost  impossible 
for  the  Department  to  strike  an  objective  bal¬ 
ance  between  the  need  to  safeguard  information 
and  the  need  to  maintain  the  free  exchange  of  in¬ 
formation.30 

Subsequent  to  the  Computer  Security  Act  of 
1987,  the  Defense  Department’s  responsibilities 
under  NSDD-145  were  aligned  by  National  Secu¬ 
rity  Directive  42  to  cover  “national  security”  tele¬ 
communications  and  information  systems.31 
NSD  42  did  not  rescind  programs,  such  as  those 
begun  under  NSDD-145,  that  pertained  to  nation¬ 
al  security  systems,  but  these  were  not  construed 
as  applying  to  systems  within  the  purview  of  the 
Computer  Security  Act  of  1987. 32 

NSD  42  established  the  National  Security  Tele¬ 
communications  and  Information  Systems  Secu¬ 
rity  Committee,  made  the  Secretary  of  Defense 
the  Executive  Agent  of  the  Government  for  Na¬ 
tional  Security  Telecommunications  and  Informa¬ 
tion  Systems,  and  designated  the  Director  of  NS  A 
the  National  Manager  for  National  Security  Tele¬ 
communications  and  Information  Systems.33  As 
such,  the  NSA  Director  was  to  coordinate  with 


NIST  in  accordance  with  the  Computer  Security 
Act  of  1987. 

[OTA  note:  The  proposal  for  a  new,  govern¬ 
ment-wide  centralization  of  unclassified  informa¬ 
tion  security,  as  presented  in  the  November  1994 
Security  Policy  Board  staff  report,  would  place 
the  functions  of  NST1SSC,  along  with  OMB}s 
functions  pursuant  to  Circular  A-130,  within  a 
new  Information  Systems  Security  Committee 
chaired  by  DOD  and  OMB,  with  NSA  as  the  secre¬ 
tariat.  The  staff  report  noted  that  this  was  con¬ 
trary  to  the  Computer  Security  Act  and  suggested 
the  need  for  a  strategy  to  ensure  a  “smooth  transi¬ 
tion ”  to  the  new  structure ,  including  creating  a 
new  definition  for  “national  security  related  in¬ 
formation.34”  See  chapter  4  and  box  1-3  of  this 
background  paper  for  discussion  of  the  Board 
staff  proposal,  along  with  discussions  of  other  de¬ 
velopments,  including  OMB’s  proposed  revision 
of  Appendix  III  of  OMB  Circular  A-130  and  the 
Paperwork  Reduction  Act  of  1995.] 

I  Agency  Information-System  Security 
Responsibilities  Under  the  Act 

Under  the  Computer  Security  Act  of  1987,  all  fed¬ 
eral  agencies  are  required  to  identify  computer 
systems  containing  sensitive  information,  and  to 
develop  security  plans  for  identified  systems.35 
The  act  also  requires  mandatory  periodic  training 
in  computer  security  for  all  federal  employees  and 
contractors  who  manage  or  use  federal  computer 
systems.  The  Computer  Security  Act  gives  final 


28  U.S.  Congress,  House  of  Representatives,  Committee  on  Government  Operations,  Computer  Security  Act  of 1 987— Report  toAccompa- 
ny  H.R.  145,  H.  Rept.  100-153,  Part  II,  100th  Cong.,  lstsess.,  June  11, 1987  (Washington,  DC:  U.S.  Government  Printing  Office,  1987),  p.  30. 

29  Ibid.,  p.  29. 

30  Ibid.,  p.  29. 

31  National  Security  Directive  42,  op.  cit.,  footnote  5.  The  National  Security  Council  released  an  unclassified,  partial  text  of  NSD  42  to  the 
Computer  Professionals  for  Social  Responsibility  on  April  1, 1992,  in  response  to  Freedom  of  Information  Act  (FOIA)  requests  made  in  1990. 

32  Ibid.,  section  10.  The  Warner  Amendment  (Public  Law  97-86)  had  exempted  certain  types  of  Defense  Department  procurements  from  the 
Brooks  Act. 

33  NSD  42  (unclassified  partial  text),  op.  cit.,  footnote  31,  sections  1-7. 

34  Security  Policy  Board  Staff,  “Creating  a  New  Order  in  U.S.  Security  Policy,”  Nov.  21,  1994,  pp.  17-18. 

35  Public  Law  100-235,  section  6. 
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authority  to  NIST  [then  NBS]  for  developing 
government-wide  standards  and  guidelines  for 
unclassified,  sensitive  information,  and  for  devel¬ 
oping  government-wide  training  programs. 

In  carrying  out  these  responsibilities,  NIST  can 
draw  upon  the  substantial  expertise  of  NSA  and 
other  relevant  agencies.  Specifically,  NIST  is  au¬ 
thorized  to  “coordinate  closely  with  other  agen¬ 
cies  and  offices,”  including  NSA,  OTA,  DOD,  the 
Department  of  Energy,  GAO,  and  OMB.36  This 
coordination  is  aimed  at  “assuring]  maximum 
use  of  all  existing  and  planned  programs,  materi¬ 
als,  studies,  and  reports  relating  to  computer  sys¬ 
tems  security  and  privacy”  and  assuring  that 
NIST’s  computer  security  standards  are  “consis¬ 
tent  and  compatible  with  standards  and  proce¬ 
dures  developed  for  the  protection  of  information 
in  federal  computer  systems  which  is  authorized 
under  criteria  established  by  Executive  order  or  an 
Act  of  Congress  to  be  kept  secret  in  the  interest  of 
national  defense  or  foreign  policy.”37  Additional¬ 
ly,  the  Computer  Security  Act  authorizes  NIST  to 
“draw  upon  computer  system  technical  security 
guidelines  developed  by  [NSA]  to  the  extent  that 
[NIST]  determines  that  such  guidelines  are  con¬ 
sistent  with  the  requirements  for  protecting  sensi¬ 
tive  information  in  federal  computer  systems.”38 
The  act  expected  that  “[t]he  method  for  promul¬ 
gating  federal  computer  system  security  standards 
and  guidelines  is  the  same  as  for  non-security 
standards  and  guidelines.”  39  The  intent  of  the  act 
was  that  NSA  not  have  the  dominant  role  and  to 
recognize  the  potential  market  impact  of  federal 
security  standards: 

. . .  [I]n  carrying  out  its  responsibilities  to  de¬ 
velop  standards  and  guidelines  for  protecting 
sensitive  information  in  federal  computer  sys¬ 


tems  and  to  perform  research,  NBS  [now  NIST] 
is  required  to  draw  upon  technical  security 
guidelines  developed  by  the  NSA  to  the  extent 
that  NBS  determines  that  NSA’s  guidelines  are 
consistent  with  the  requirements  of  civil  agen¬ 
cies.  The  purpose  of  this  language  is  to  prevent 
unnecessary  duplication  and  promote  the  high¬ 
est  degree  of  cooperation  between  these  two 
agencies.  NBS  will  treat  NSA  technical  security 
guidelines  as  advisory,  however,  and,  in  cases 
where  civil  agency  needs  will  best  be  served  by 
standards  that  are  not  consistent  with  NSA 
guidelines,  NBS  may  develop  standards  that 
best  satisfy  the  agencies’  needs. 

It  is  important  to  note  the  computer  security 
standards  and  guidelines  developed  pursuant  to 
H.R.  145  are  intended  to  protect  sensitive  in¬ 
formation  in  Federal  computer  systems.  Never¬ 
theless,  these  standards  and  guidelines  will 
strongly  influence  security  measures  imple¬ 
mented  in  the  private  sector.  For  this  reason, 
NBS  should  consider  the  effect  of  its  standards 
on  the  ability  of  U.S.  computer  system  manufac¬ 
turers  to  remain  competitive  in  the  international 
marketplace.40 

In  its  report  accompanying  H.R.  145,  the  Com¬ 
mittee  on  Government  Operations  noted  that: 

While  the  Committee  was  considering  H.R. 
145,  proposals  were  made  to  modify  the  bill  to 
give  NSA  effective  control  over  the  computer 
standards  program.  The  proposals  would  have 
charged  NSA  with  the  task  of  developing  “tech¬ 
nical  guidelines,”  and  forced  NBS  to  use  these 
guidelines  in  issuing  standards. 

Since  work  on  technical  security  standards 
represents  virtually  all  of  the  research  effort  be¬ 
ing  done  today,  NSA  would  take  over  virtually 
the  entire  computer  standards  from  the  National 


36  Ibid.,  section  3(b)(6). 

37  Ibid. 

38  Ibid. 

39  H.  Rept.  100-153,  Part  I,  op.  cit.,  footnote  12,  p.  26.  According  to  NIST,  security  FIPS  are  issued  in  the  same  manner  as  for  nonsecurity 
FIPS.  Although  the  Escrowed  Encryption  Standard  (EES)  has  classified  references,  it  had  the  same  promulgation  method.  (F.  Lynn  McNulty, 
Associate  Director  for  Computer  Security,  NIST,  personal  communication,  Mar.  21,  1995.) 

40  Ibid.,  p.  27. 
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Bureau  of  Standards.  By  putting  NSA  in  charge 
of  developing  technical  security  guidelines 
(software,  hardware,  communications),  NBS 
would  be  left  with  the  responsibility  for  only  ad¬ 
ministrative  and  physical  security  measures — 
which  have  generally  been  done  years  ago. 
NBS,  in  effect,  would  on  the  surface  be  given  the 
responsibility  for  the  computer  standards  pro¬ 
gram  with  little  to  say  about  most  of  the  pro¬ 
gram — the  technical  guidelines  developed  by 
NSA. 

This  would  jeopardize  the  entire  Federal 
standards  program.  The  development  of  stan¬ 
dards  requires  interaction  with  many  segments 
of  our  society,  i.e.,  government  agencies,  com¬ 
puter  and  communications  industry,  interna¬ 
tional  organizations,  etc.  NBS  has  performed 
this  kind  of  activity  very  well  over  the  last  22 
years  [since  enactment  of  the  Brooks  Act  of 
1965].  NSA,  on  the  other  hand,  is  unfamiliar 
with  it.  Further,  NSA’s  products  may  not  be  use¬ 
ful  to  civilian  agencies  and,  in  that  case,  NBS 
would  have  no  alternative  but  to  issue  standards 
based  on  these  products  or  issue  no  standards  at 
all.41 

The  Committee  on  Government  Operations  also 
noted  the  concerns  of  industry  and  the  research 
community  regarding  the  effects  of  export  con¬ 
trols  and  NSA  involvement  in  private  sector  acti¬ 
vities,  including  restraint  of  innovation  in 
cryptography  resulting  from  reduced  incentives 
for  the  private  sector  to  invest  in  independent  re¬ 
search,  development,  and  production  of  products 
incorporating  cryptography.42 

The  Computer  Security  Act  of  1987  estab¬ 
lished  a  Computer  System  Security  and  Privacy 


Advisory  Board  (CSSPAB)  within  the  Commerce 
Department: 

The  chief  purpose  of  the  Board  is  to  assure 
that  NBS  receives  qualified  input  from  those 
likely  to  be  affected  by  its  standards  and  guide¬ 
lines,  both  in  government  and  the  private  sector. 
Specifically,  the  duties  of  the  Board  are  to  iden¬ 
tify  emerging  managerial,  technical,  adminis¬ 
trative  and  physical  safeguard  issues  relative  to 
computer  systems  security  and  privacy  and  to 
advise  the  NBS  and  the  Secretary  of  Commerce 
on  security  and  privacy  issues  pertaining  to  fed¬ 
eral  computer  systems.43 

The  Chair  of  the  CSSPAB  is  appointed  by  the  Sec¬ 
retary  of  Commerce.  The  Board  is  required  to  re¬ 
port  its  findings  relating  to  computer  systems 
security  and  privacy  to  the  Secretary  of  Com¬ 
merce,  the  OMB  Director,  the  NSA  Director,  the 
House  Committee  on  Government  Operations, 
and  the  Senate  Committee  on  Governmental  Af¬ 
fairs  44 

I  Implementation  Issues 

Implementation  of  the  Computer  Security  Act  has 
been  controversial,  particularly  with  respect  to  the 
roles  of  NIST  and  NSA  in  standards  development. 
The  two  agencies  developed  a  Memorandum  of 
Understanding  in  1989  to  clarify  the  working  rela¬ 
tionship,  but  this  MOU  has  been  controversial  as 
well,  because  of  concerns  in  Congress  and  else¬ 
where  that  its  provisions  cede  NSA  much  more 
authority  than  the  act  had  granted  or  envisioned  45 
Chapter  4  of  the  1994  OTA  report  examined  these 
implementation  issues  in  depth.  It  concluded  that 
clear  policy  guidance  and  congressional  oversight 


41  H.  Rept.  100-153,  Part  II,  op.  cit.,  footnote  28,  pp.  25-26. 

42  Ibid.,  pp.  22-25, 30-35.  In  1986,  NSA  had  announced  a  program  to  develop  tamperproof  cryptographic  modules  that  qualified  commu¬ 
nications  manufacturers  could  embed  in  their  products.  NSA’s  development  of  these  embeddable  modules  was  part  of  NSA  s  Development 
Center  for  Embedded  COMSEC  Products.  (NSA  press  release  for  Development  Center  for  Embedded  COMSEC  Products,  Jan.  10,  1986.) 

43  H.  Rept.  100-153,  Part  I,  op.  cit.,  footnote  12,  pp.  27-28. 

44  Public  Law  100-235,  section  3. 

45  The  manner  in  which  NIST  and  NSA  planned  to  execute  their  functions  under  the  Computer  Security  Act  of  1987,  as  evidenced  by  the 
MOU,  was  the  subject  of  hearings  in  1989.  See  U.S.  Congress,  House  of  Representatives,  Subcommittee  on  Legislation  and  National  Security, 
Committee  on  Government  Operations,  Military  and  Civilian  Control  of  Computer  Security  Issues,  101st  Cong.,  1st  sess.,  May  4, 1989  (Wash¬ 
ington,  DC:  U.S .  Government  Printing  Office,  1989).  The  NIST-NS  A  working  relationship  has  subsequently  been  raised  as  an  issue,  with  regard 
to  the  EES  and  the  DSS.  See  OTA,  op.  cit.,  footnote  1,  ch.  4  and  app.  C. 
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will  be  needed  if  NIST/NSA  processes  and  out¬ 
comes  are  to  reflect  a  different  balance  of  national 
security  and  other  objectives,  or  more  openness, 
than  have  been  evidenced  since  1989. 

The  Computer  Security  Act  of  1 987  requires  all 
federal  agencies  to  identify  computer  systems 
containing  sensitive  information,  and  to  develop 
security  plans  for  these  systems.46  The  act  also  re¬ 
quires  mandatory  periodic  training  in  computer 
security  for  all  federal  employees  and  contractors 
who  manage,  use,  or  operate  federal  computer 
systems.  In  its  workshops  and  discussions  with 
federal  employees  and  knowledgeable  outside  ob¬ 
servers,  OTA  found  that  these  provisions  of  the 
Computer  Security  Act  are  viewed  as  generally 
adequate  as  written,  but  that  their  implementation 
can  be  problematic.47 

During  the  course  of  the  assessment  and  fol¬ 
low-on  work,  OTA  found  strong  sentiment  that 
agencies  follow  the  rules  set  forth  by  the  Comput¬ 
er  Security  Act,  but  not  necessarily  the  full  intent 
of  the  act.  In  practice,  there  are  both  insufficient 
incentives  for  compliance  and  insufficient  sanc¬ 
tions  for  noncompliance  with  the  spirit  of  the  act. 
For  example,  though  agencies  do  develop  the  re¬ 
quired  security  plans,  the  act  does  not  require 
agencies  to  review  them  periodically  or  update 
them  as  technologies  or  circumstances  change. 
One  result  of  this  is  that  “[sjecurity  of  systems 
tends  to  atrophy  over  time  unless  there  is  a  stimu¬ 
lus  to  remind  agencies  of  its  importance.”48 
Another  result  is  that  agencies  may  not  treat  secu¬ 


rity  as  an  integral  component  when  new  systems 
are  being  designed  and  developed. 

Ongoing  NIST  activities  in  support  of  informa¬ 
tion  security  and  privacy  are  conducted  by  NIST’s 
Computer  Systems  Laboratory.  In  the  1994  re¬ 
port,  OTA  noted  that  NIST’s  funding  for  these  se¬ 
curity  functions  ($4.5  million  in  appropriated 
funds  for  FY  1995)  has  chronically  been  low,  giv¬ 
en  NIST’s  responsibilities  under  the  Computer 
Security  Act.  “Reimbursable”  funds  received 
from  other  agencies  (mainly  DOD)  have  been  sub¬ 
stantial  ($2.0  million  in  FY  1995)  compared  with 
appropriated  funds  for  security-related  activities. 
Since  FY  1990,  they  have  represented  some  30  to 
40  percent  of  the  total  funding  for  computer-secu¬ 
rity  activities  and  staff  at  CSL.  This  is  a  large  frac¬ 
tion  of  what  has  been  a  relatively  small  budget 
(about  $6.5  million  total  in  FY  1995). 

Some  of  the  possible  measures  to  improve  im¬ 
plementation  were  mentioned  during  OTA  staff 
interviews  and  workshops  circa  1993-94  includ¬ 
ing  the  following:  increasing  resources  for  OMB 
to  coordinate  and  oversee  agency  security  plans 
and  training;  increasing  resources  for  NIST  and/or 
other  agencies  to  advise  and  review  agency  securi¬ 
ty  plans  and  training;  setting  aside  part  of  agency 
budgets  for  information  security  (to  be  used  for 
risk  assessment,  training,  development,  etc.);  and/ 
or  rating  agencies  according  to  the  adequacy  and 
effectiveness  of  their  information-security  poli¬ 
cies  and  plans  and  withholding  funds  until  perfor¬ 
mance  meets  predetermined  accepted  levels. 


46  Public  Law  100-235,  section  6. 

47  Some  of  the  possible  measures  to  improve  implementation  that  were  suggested  during  these  discussions  were:  increasing  resources  for 
OMB  to  coordinate  and  oversee  agency  security  plans  and  training;  increasing  resources  for  NIST  and/or  other  agencies  to  advise  and  review 
agency  security  plans  and  training;  setting  aside  part  of  agency  budgets  for  information  security  (to  be  used  for  risk  assessment,  training,  devel¬ 
opment,  and  so  forth);  and/or  rating  agencies  according  to  the  adequacy  and  effectiveness  of  their  information-security  policies  and  plans  and 
withholding  funds  until  performance  meets  predetermined  accepted  levels.  (Discussions  in  OTA  workshops  and  interviews,  1993-94.) 

48  Office  of  Management  and  Budget  (in  conjunction  with  NIST  and  NS  A),  “Observations  of  Agency  Computer  Security  Practices  and 
Implementation  of  OMB  Bulletin  No.  90-08:  Guidance  for  Preparation  of  Security  Plans  for  Federal  Computer  Systems  That  Contain  Sensitive 
Information,”  February  1993,  p.  11. 
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The  United  States  has  two  regulatory  re¬ 
gimes  for  exports,  depending  on  whether 
the  item  to  be  exported  is  military  in  na¬ 
ture,  or  is  “dual-use,”  having  both  civilian 
and  military  uses.  These  regimes  are  administered 
by  the  State  Department  and  the  Commerce  De¬ 
partment,  respectively.  Both  regimes  provide  ex¬ 
port  controls  on  selected  goods  or  technologies  for 
reasons  of  national  security  or  foreign  policy.  Li¬ 
censes  are  required  to  export  products,  services,  or 
scientific  and  technical  data1  originating  in  the 
United  States,  or  to  re-export  these  from  another 
country. 


Licensing  requirements  vary  according  to  the 
nature  of  the  item  to  be  exported,  the  end  use,  the 
end  user,  and,  in  some  cases,  the  intended  destina¬ 
tion.  For  many  items  that  are  under  Commerce  ju¬ 
risdiction,  no  specific  approval  is  required  and  a 
“general  license”  applies  (e.g.,  when  the  item  in 
question  is  not  military  or  dual-use  and/or  is  wide¬ 
ly  available  from  foreign  sources).  In  other  cases, 
an  export  license  must  be  applied  for  from  either 
the  State  Department  or  the  Commerce  Depart¬ 
ment,  depending  on  the  nature  of  the  item.  In 
general,  the  State  Department’s  licensing  require¬ 
ments  are  more  stringent  and  broader  in  scope.2 


1  Both  the  Export  Administration  Act  (50  U.S.C.  App.  2401-2420)  and  the  Arms  Export  Control  Act  (22  U.S.C.  2751-2794)  provide  author¬ 
ity  to  control  the  dissemination  to  foreign  nationals  (export)  of  scientific  and  technical  data  related  to  items  requiring  export  licenses  under  the 
regulations  implementing  these  acts.  “Scientific  and  technical  data”  can  include  plans,  design  specifications,  or  other  information  that  describes 
how  to  produce  an  item.  See  U.S.  Congress,  Office  of  Technology  Assessment,  Information  Security  and  Privacy  in  Network  Environments, 
OTA-TCT-606  (Washington,  DC;  U.S.  Government  Printing  Office,  September  1994),  pp.  150-160. 

Other  statutory  authorities  for  national  security  controls  on  scientific  and  technical  data  are  found  in  the  Restricted  Data  or  “bom  classified” 
provisions  of  the  Atomic  Energy  Act  of  1946  (60  Stat.  755)  and  the  Atomic  Energy  Act  of  1954  (68  Stat.  919, 42  U.S.C.  2011-2296),  and  in  the 
Invention  Secrecy  Act  of  1951  (35  U.S.C.  181-188),  which  allows  for  patent  secrecy  orders  and  withholding  of  patents  on  national  security 
grounds.  NSA  has  obtained  patent  secrecy  orders  on  patent  applications  for  cryptographic  equipment  and  algorithms  under  authority  of  the 
Invention  Secrecy  Act. 

2  For  another  comparison  of  the  two  export-control  regimes,  see  U.S.  General  Accounting  Office,  Export  Controls:  Issues  in  Removing 
Militarily  Sensitive  Items  from  the  Munitions  List,  GAO/NSIAD-93-67  (Washington,  DC:  U.S.  Government  Printing  Office,  March  1993),  esp. 
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The  material  in  this  appendix  is  taken  from  pages 
150-160  of  the  1994  OTA  report,  updated  where 
appropriate.  Licensing  terms  differ  between  the 
agencies,  as  do  time  frames  and  procedures  for  li¬ 
censing  review,  revocation,  and  appeal. 

STATE  DEPARTMENT  EXPORT 
CONTROLS  ON  CRYPTOGRAPHY 

The  Arms  Export  Control  Act  and  International 
Traffic  in  Arms  Regulations  (ITAR),3  adminis¬ 
tered  by  the  State  Department,  control  export  of 
items  (including  hardware,  software,  and  techni¬ 
cal  data)  that  are  “inherently  military  in  character” 
and,  therefore,  placed  on  the  Munitions  List.4  Un¬ 
less  otherwise  indicated,  items  on  the  Munitions 
List  are  controlled  to  all  destinations,  meaning 
that  “validated”  licenses — requiring  case-by-case 
review — are  required  for  any  exports  (except  to 
Canada,  in  some  cases).  The  Munitions  List  is  es¬ 
tablished  by  the  State  Department,  in  concurrence 
with  the  Defense  Department;  the  State  Depart¬ 
ment’s  Office  of  Defense  Trade  Controls  adminis¬ 
ters  the  ITAR  and  issues  licenses  for  approved 
exports.  The  Defense  Department  provides  tech¬ 
nical  advice  to  the  State  Department  when  there 
are  questions  concerning  license  applications  or 
commodity  jurisdiction  (i.e.,  whether  State  or 
Commerce  regulations  apply — see  below). 

With  certain  exceptions,  cryptography  falls  in 
“Category  XIII — Auxiliary  Military  Equipment” 
of  the  Munitions  List.  Category  XIII(b)  covers 
“Information  Security  Systems  and  equipment, 
cryptographic  devices,  software  and  components 
specifically  designed  or  modified  therefore,”  gen¬ 
erally  including: 

1.  cryptographic  and  key-management  systems 
and  associated  equipment,  subcomponents, 
and  software  capable  of  maintaining  informa¬ 


tion  or  information-system  secrecy/confiden¬ 
tiality; 

2.  cryptographic  and  key-management  systems 
and  associated  equipment,  subcomponents, 
and  software  capable  of  generating  spreading 
or  hopping  codes  for  spread-spectrum  systems 
or  equipment; 

3.  cryptanalytic  systems  and  associated  equip¬ 
ment,  subcomponents,  and  software; 

4.  systems,  equipment,  subcomponents  and  soft¬ 
ware  capable  of  providing  multilevel  security 
that  exceeds  class  B2  of  the  National  Security 
Agency’s  (NSA’s)  Trusted  Computer  System 
Evaluation  Criteria,  as  well  as  software  used 
for  certification; 

5.  ancillary  equipment  specifically  designed  or 
modified  for  these  functions;  and 

6.  technical  data  and  defense  services  related  to 
the  above.5 

Several  exceptions  apply  to  item  XIII(b)(l) 

above.  These  include  the  following  subcategories 

of  cryptographic  hardware  and  software: 

a.  those  used  to  decrypt  copy-protected  software, 
provided  that  the  decryption  functions  are  not 
user-accessible; 

b.  those  used  only  in  banking  or  money  transac¬ 
tions  (e.g.,  in  ATM  machines  and  point-of-sale 
terminals,  or  for  encrypting  interbanking  trans¬ 
actions); 

c.  those  that  use  analog  (not  digital)  techniques 
for  cryptographic  processing  in  certain  applica¬ 
tions,  including  facsimile  equipment,  re¬ 
stricted-audience  broadcast  equipment,  and 
civil  television  equipment; 

d.  those  used  in  personalized  smart  cards  when 
the  cryptography  is  of  a  type  restricted  for  use 
only  in  applications  exempted  from  Munitions 
List  controls  (e.g.,  in  banking  applications); 


3  22  C.F.R.  120-130. 

4  See  Supplement  2  to  Part  770  of  the  Export  Administration  Regulations.  The  Munitions  List  has  2 1  categories  of  items  and  related  technol¬ 
ogies,  such  as  artillery  and  projectiles  (Category  II)  or  toxicological  and  radiological  agents  and  equipment  (Category  XIV).  Category  XIII(b) 
consists  of  “Information  Security  Systems  and  equipment,  cryptographic  devices,  software,  and  components  specifically  modified  therefore.” 

5  Ibid.  See  Category  XIII(b)((l)-(5))  and  XIII(k).  For  a  review  of  controversy  during  the  1970s  and  early  1 980s  concerning  control  of  cryp¬ 
tographic  publication,  see  F.  Weingarten,  “Controlling  Cryptographic  Publication,”  Computers  &  Security,  vol.  2,  1983,  pp.  41-48. 
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e.  those  limited  to  access-control  functions  (e.g., 
for  ATM  machines,  point-of-sale  terminals, 
etc.)  in  order  to  protect  passwords,  personal 
identification  numbers,  and  the  like  provided 
that  they  do  not  provide  for  encryption  of  other 
files  or  text; 

f.  those  limited  to  data  authentication  (e.g.,  calcu¬ 
lating  a  message  authentication  code)  but  not 
allowing  general  file  encryption; 

g.  those  limited  to  receiving  radio  broadcast,  pay 
television,  or.  other  consumer-type  restricted 
audience  broadcasts,  where  digital  decryption' 
is  limited  to  the  video,  audio,  or  management 
functions  and  there  are  no  digital  encryption  ca¬ 
pabilities;  and 

h.  those  for  software  designed  or  modified  to  pro¬ 
tect  against  malicious  computer  damage  from 
viruses,  and  so  forth.6 

Cryptographic  hardware  and  software  in  these 
subcategories  are  excluded  from  the  ITAR  regime 
and  fall  under  Commerce’s  jurisdiction.  Note, 
however,  that  these  exclusions  do  not  include 
hardware-based  products  for  encrypting  data  or 
other  files  before  transmission  or  storage,  or  user- 
accessible,  digital  encryption  software  for  ensur¬ 
ing  email  confidentiality  or  read-protecting  stored 
data  or  text  files.  These  remain  under  State  De¬ 
partment  control. 

In  September  1994,  the  State  Department  an¬ 
nounced  an  amendment  to  the  regulations  imple¬ 
menting  section  38  of  the  Arms  Export  Control 
Act.7  The  new  rule  implements  one  of  the  reforms 
applicable  to  encryption  products  that  were  an¬ 
nounced  on  February  4, 1 994,  by  the  State  Depart¬ 


ment.8  It  established  a  new  licensing  procedure  in 
the  ITAR  to  permit  U.S .  encryption  manufacturers 
to  make  multiple  shipments  of  items  covered  by 
Category  XIII(b)(l)  of  the  Munitions  List  (see 
above)  directly  to  end  users  in  an  approved  coun¬ 
try,  without  obtaining  individual  licenses.  Pre¬ 
viously,  only  those  exports  covered  by  a 
distribution  arrangement  could  be  shipped  with¬ 
out  an  individual  license;  the  new  procedure  per¬ 
mits  direct  distribution  from  manufacturers 
without  foreign  distributors.  The  procedures  are 
similar  to  existing  distribution  agreement  proce¬ 
dures;  exporters  submit  a  proposed  arrangement 
specifying  items  to  be  shipped,  proposed  end  us¬ 
ers  and  uses,  and  destination  countries.  Upon  ap¬ 
proval,  exporters  can  ship  the  specified  products 
directly  to  the  end  users  in  the  approved  countries, 
with  a  single  license.9  Among  the  other  reforms 
announced  in  February  1994  but  awaiting  imple¬ 
mentation  are  special  licensing  procedures  that 
would  permit  export  of  key-escrow  encryption 
products  to  “most”  end  users.16 

COMMERCE  DEPARTMENT  EXPORT 
CONTROLS  ON  CRYPTOGRAPHY 

The  Export  Administration  Act  (EAA)11  and  Ex¬ 
port  Administration  Regulations  (EAR),12  ad¬ 
ministered  by  the  Commerce  Department,  are 
designed  to  control  exports  of  “sensitive”  or  dual- 
use  items,  including  software  and  scientific  and 
technical  data.  Some  items  on  the  Commerce 
Control  List  (CCL)  are  controlled  for  national  se¬ 
curity  purposes,  to  prevent  them  from  reaching 
“proscribed”  countries  (usually  in  the  former  So- 


6  Munitions  List,  ibid.  See  XIII(b)  (1)  (i)-(ix). 

7  Department  of  State,  Bureau  of  Political-Military  Affairs,  22  CFR  parts  123  and  124,  Federal  Register ,  vol.  59,  No.  170,  Sept.  2, 1994,  pp. 
45621-45623. 

8  Martha  Harris,  Deputy  Assistant  Secretary  for  Political-Military  Affairs,  U.S.  Department  of  State,  “Encryption— Export  Control  Re¬ 
form,”  statement,  Feb.  4,  1994. 

9  Federal  Register ,  op.  cit.,  footnote  7,  p.  45621. 

10  Martha  Harris,  op.  cit.,  footnote  8. 

1 1  At  this  writing,  the  export  administration  legislation  is  to  be  reauthorized. 

12  22  U.S.C.  2751-2794. 
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vietbloc);  others  are  controlled  for  various  foreign 
policy  objectives.13 

The  Bureau  of  Export  Administration  adminis¬ 
ters  controls  on  dual-use  items.  The  Bureau  of  Ex¬ 
port  Administration’s  Office  of  Strategic  Trade 
and  Foreign  Policy  Controls 14  is  responsible  for 
making  licensing  determinations,  coordinating 
with  other  responsible  agencies  as  necessary,  and 
maintaining  the  Commerce  Control  List  for  cryp¬ 
tographic  products.15 

Cryptography  falls  under  Section  II  (“Informa¬ 
tion  Security”)  of  the  CCL.16  This  category 
includes  information-security  “equipment,  as¬ 
semblies  and  components”  that: 

1 .  are  designed  or  modified  to  use  digital  cryptog¬ 
raphy  for  information  security; 

2.  are  designed  or  modified  to  use  cryptanalytic 
functions; 

3.  are  designed  or  modified  to  use  analog  cryptog¬ 
raphy,  except  for  some  low-speed,  fixed  band 
scrambling  or  frequency  inversion,  or  in  fac¬ 
simile  equipment,  restricted  audience  broad¬ 
cast  equipment  or  civil  television  equipment 
(see  item  c  above); 

4.  are  designed  to  suppress  compromising  emana¬ 
tions  of  information-bearing  signals,  except  for 
suppression  of  emanations  for  health  or  safety 
reasons; 

5 .  are  designed  or  modified  to  use  cryptography  to 
generate  the  spreading  code  for  spread-spec¬ 
trum  systems  or  the  hopping  code  for  frequency 
agility  systems;  or 


6.  are  designed  or  modified  to  exceed  class  B2  of 
the  Trusted  Computer  System  Evaluation  Cri¬ 
teria  (see  item  4  in  the  State  Department  list 
above);  plus  those  that 

7.  are  communications  cable  systems  with  intru¬ 
sion-detection  capabilities. 

Equipment  for  the  test,  inspection,  and  production 
(including  evaluation  and  validation  equipment) 
of  equipment  or  functions  in  this  category  are  in¬ 
cluded,  as  are  related  software  and  technology. 

OVERLAP  BETWEEN 
CONTROL  REGIMES 

The  “overlap”  between  the  State  Department  and 
Commerce  Department  export-control  regimes  is 
particularly  complex  for  cryptography  (note  the 
overlap  between  the  Munitions  List  items  and  the 
CCL  items  shown  above,  even  with  the  excep¬ 
tions).  Basically,  the  Commerce  Department  li¬ 
censes  only  those  Section  II  items  that  are  either 
excepted  from  State  Department  control,  are  not 
controlled,  or  are  eligible  for  licensing  under  an 
advisory  note,  plus  anti  virus  software  (see  item  h 
in  the  section  on  State  Department  controls 
above).17  The  cryptographic  items  exempted 
from  control  under  advisory  note  1  are:  personal¬ 
ized  smart  cards  as  described  in  item  d  above; 
equipment  for  fixed  data  compression  or  coding 
techniques,  or  for  use  in  applications  described  in 
item  g  above;  portable,  commercial  civil  cellular 
phones  containing  encryption,  when  accompany- 


13  See  GAO,  op.  cit.,  footnote  2,  pp.  10-12. 

14  The  functions  of  the  Office  of  Export  Licensing  and  the  Office  of  Technology  and  Policy  Analysis  were  merged  and  shifted  after  a  reorga¬ 
nization  of  the  Bureau  of  Export  Administration  in  late  1994-early  1995.  (Maurice  Cook,  Bureau  of  Export  Administration,  Economic  Analysis 
Division,  personal  communication,  Mar.  17,  1995.) 

15  Joseph  Young,  Office  of  Strategic  Trade  and  Foreign  Policy  Controls,  Bureau  of  Export  Administration,  personal  communication,  Mar. 
23, 1995. 

16  See  Supplement  1  to  Part  799.1  of  the  Export  Administration  Regulations,  sections  A  (equipment,  assemblies  and  components),  B  (test, 
inspection,  and  production  equipment),  D  (software),  and  E  (technology). 

17  Ibid.,  p.  CCL123  (notes).  The  advisory  notes  specify  items  that  can  be  licensed  by  Commerce  under  one  or  more  administrative  excep¬ 
tions. 
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ing  their  users;  and  software  as  described  in  item  a 
above.18  Other  items,  such  as  cellular  phone  sys¬ 
tems  for  which  message  traffic  encryption  is  not 
possible  or  items  for  civilian  use  in  banking,  ac¬ 
cess  control,  and  authentication  as  described  un¬ 
der  items  b),  e),  or  f)  above,  are  covered  by 
advisory  notes  3  through  5.  These  advisory  notes 
state  that  these  items  are  likely  to  be  licensed  by 
Commerce,  as  administrative  exceptions,  for  ex¬ 
port  to  acceptable  end  users.19 

At  present,  software  and  hardware  for  robust, 
user-controlled  encryption  remains  on  the  Muni¬ 
tions  List  under  State  Department  control,  unless 
State  grants  jurisdiction  to  Commerce.20  This  has 
become  increasingly  controversial,  especially  for 
the  information  technology  and  software  indus¬ 
tries.  According  to  the  U.S.  General  Accounting 
Office’s  (GAO’s)  1993  report: 

NSA  performs  the  technical  review  that  deter¬ 
mines,  for  national  security  reasons,  (1)  if  a  product 
with  encryption  capabilities  is  a  munitions  item  or  a 
Commerce  List  item  and  (2)  which  munitions  items 
with  encryption  capabilities  may  be  exported.  The 
Department  of  State  examines  the  NSA  determina¬ 
tion  for  consistency  with  prior  NSA  determinations 
and  may  add  export  restrictions  for  foreign  policy 
reasons — e.g.,  all  exports  to  certain  countries  may 
be  banned  for  a  time  period. 

. . .  [T]he  detailed  criteria  for  these  decisions  are 
generally  classified.  However,  vendors  exporting 
these  items  can  learn  some  of  the  general  criteria 
through  prior  export  approvals  or  denials  they  have 
received.  NSA  representatives  also  advise  compa¬ 
nies  regarding  whether  products  they  are  planning 
would  likely  be  munitions  items  and  whether  they 
would  be  exportable,  according  to  State  Depart¬ 
ment  representatives.21 


At  the  end  of  COCOM  in  1994,  the  Clinton  Ad¬ 
ministration  liberalized  the  policy  for  some  ex¬ 
ports  of  computer  and  telecommunications 
products  to  Russia,  Eastern  Europe,  and  China. 
However,  controls  were  maintained  on  cryptogra¬ 
phy  because: 

The  President  has  determined  that  vital  U.S. 
national  security  and  law  enforcement  interests 
compel  maintaining  appropriate  control  of  encryp¬ 
tion  22 

In  1992,  there  had  been  limited  relaxation  of  ex¬ 
port  controls  for  mass-marketed  software  with 
encryption  capabilities.  NSA  and  the  State  De¬ 
partment  relaxed  and  streamlined  export  controls 
for  mass-market  software  with  moderate  encryp¬ 
tion  capabilities,  but  not  including  software  im¬ 
plementing  the  Data  Encryption  Standard  (DES) 
or  computer  hardware  containing  encryption  al¬ 
gorithms.23  Also,  since  July  1992,  there  has  been 
expedited  review  of  software  using  one  of  two  al¬ 
gorithms  developed  by  RSA  Data  Security,  Inc. 
These  algorithms,  called  RC2  and  RC4,  are  said  to 
be  significantly  stronger  than  those  previously  al¬ 
lowed  for  export,  but  are  limited  to  a  40-bit  key 
length  and  are  said  to  be  weaker  than  the  “DES- 
strength”  programs  that  can  be  marketed  in  the 
United  States  and  that  are  available  overseas. 

U.S.  software  producers  still  face  the  ITAR  re¬ 
strictions  (with  the  new,  expedited-distribution 
rule  noted  above)  for  exports  of  software  with 
strong  encryption.24  Software  or  hardware  prod¬ 
ucts  using  the  DES  for  message  encryption  (as  op¬ 
posed  to  message  authentication)  are  on  the 
Munitions  List  and  are  generally  nonexportable  to 
foreign  commercial  users,  except  foreign  subsid¬ 
iaries  of  U.S.  firms  and  some  financial  institutions 


18  Ibid.,  pp.  CCL123-126.  Software  required  for  or  providing  these  functions  is  also  excepted. 

19  Ibid.,  Advisory  Notes  1-5. 

20  GAO,  op.  cit.,  footnote  2,  pp.  24-28. 

21  Ibid.,  p.  25. 

22  Martha  Harris,  op.  cit.,  footnote  8. 

23  Ibid. 

24  “Strong”  encryption  in  this  context  refers  to  systems  on  a  par  with  the  DES  or  with  the  RSA  system  with  a  1,024-bit  modulus. 
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(for  use  in  electronic  funds  transfers).  Products 
that  use  the  DES  and  other  algorithms  for  pur¬ 
poses  other  than  message  encryption  (e.g.,  for  au¬ 
thentication)  can  be  exported  on  the  Commerce 
Control  List,  however.25 

In  the  103d  Congress,  legislation  intended  to 
streamline  controls  and  ease  restrictions  on  mass- 
market  computer  software,  hardware,  and  tech¬ 
nology,  including  certain  encryption  software, 


had  been  introduced.  No  export  legislation  was 
enacted,  however,  and  the  last  reported  version  of 
the  House  legislation  did  not  include  these  provi¬ 
sions.26  In  the  104th  Congress,  omnibus  export 
administration  legislation  for  1995  has  been 
introduced  in  the  House  (H.R.  361).  At  this  writ¬ 
ing,  it  does  not  have  special  provisions  for  cryp¬ 
tography. 


25  GAO,  op.  cit.,  footnote  2,  p.  26.  For  discussion  of  industry  and  government  views,  OTA,  op.  cit.,  footnote  1,  pp.  154-160. 

26  See  U.S.  Congress,  House  of  Representatives,  Omnibus  Export  Administration  Act  of 1994,  H.  Rept.  103-531 , 103d  Cong.,  2d  sess.,  Parts 
1  (Committee  on  Foreign  Affairs,  May  25, 1994),  2  (Permanent  Select  Committee  on  Intelligence,  June  16, 1994),  3  (Committee  on  Ways  and 
Means,  June  7,  1994),  and  4  (Committee  on  Armed  Services,  June  17, 1994)  (Washington,  DC,  U.S.  Government  Printing  Office,  1994);  and 
H.R.  4663,  “Omnibus  Export  Administration  Act  of  1994,”  June  28,  1994. 
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Part  of  the  motivation  for  the  OTA  report  In¬ 
formation  Security  and  Privacy  in  Net¬ 
work  Environments  was  the  recognition 
that  we  are  in  transition  to  a  society  that  is 
becoming  critically  dependent  on  electronic  in¬ 
formation  and  network  connectivity.  This  is  ex¬ 
emplified  by  the  explosive  growth  of  the  Internet 
and  sources  of  online  information  and  entertain¬ 
ment.1 

The  need  for  congressional  attention  to  safe¬ 
guarding  information  has  been  reinforced  in  the 
months  since  the  report  was  issued  in  September 
1994.  The  use  of  information  networks  for  busi¬ 
ness  has  continued  to  expand,  and  ventures  to 


bring  electronic  commerce  and  “electronic  cash” 
into  homes  and  offices  are  materializing  rapidly.2 
Government  agencies  have  continued  to  expand 
both  the  scale  and  scope  of  their  network  connecti¬ 
vities.  Information  technologies  and  networks  are 
featured  even  more  prominently  in  plans  to  make 
government  more  efficient,  effective,  and  respon¬ 
sive.3 

Concerns  for  the  security  and  privacy  of  net¬ 
worked  information  remain.  In  its  1994  report, 
OTA  found  that  the  fast-changing  and  competitive 
marketplace  that  produced  the  Internet  and  a 
strong  networking  and  software  industry  in  the 


1  For  example,  the  number  of  Internet  users  has  been  more  than  doubling  each  year;  some  30  million  people  worldwide  can  exchange  mes¬ 
sages  over  the  Internet.  “Browsing”  and  “chatting”  online  at  home  and  in  the  office  is  increasingly  popular— see,  e.g.,  Molly  O’Neill,  “The  Lure 
and  Addiction  of  Life  On  Line,”  The  New  York  Times ,  Mar.  8,  1995,  pp.  Cl,  C6. 

2  See,  e.g.,  Randy  Barrett,  “Hauling  In  the  Network— Behind  the  World’s  Digital  Cash  Curve,”  Washington  Technology ,  Oct.  27, 1994,  p.  18; 
Neil  Munro,  “Branch  Banks  Go  Way  of  the  Drive-In,”  Washington  Technology,  Feb.  23,  1995,  pp.  1,48;  Amy  Cortese  et  al.,  “Cashing  In  on 
Cyberspace:  A  Rush  of  Software  Development  to  Create  an  Electronic  Marketplace,”  Business  Week,  Feb.  27, 1995,  pp.  78-86;  Bob  Metcalfe, 
“Internet  Digital  Cash — Don’t  Leave  Your  Home  Page  Without  It,”  InfoWorld,  Mar.  13, 1995,  p.  55;  “Netscape  Signs  Up  19  Users  for  Its  System 
of  Internet  Security,”  The  Wall  Street  Journal,  Mar.  20, 1995,  p.  B3;  and  Saul  Hansell,  “VISA  Will  Put  a  Microchip  in  New  Cards— Product  Is 
Designed  for  Small  Purchases,”  The  New  York  Times,  Mar.  21,  1995,  p.  D3. 

3  See,  e.g.,  Neil  Munro,  “Feds  May  Get  New  Infotech  Executive,”  Washington  Technology,  Feb.  23,  1995,  pp.  1, 49;  Charles  A  Bowsher, 
Comptroller  General  of  the  United  States,  “Government  Reform:  Using  Reengineering  and  Technology  to  Improve  Government  Perfor¬ 
mance,”  GAO/T-OCG-95-2,  testimony  before  the  Committee  on  Governmental  Affairs,  U.S.  Senate,  Feb.  2, 1995;  and  Elena  Varon,  “Reinvent¬ 
ing  Is  Old  Hat  for  New  Chairman,”  Federal  Computer  Week,  Feb.  20,  1995,  pp.  22,  27. 
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United  States  has  not  consistently  produced  prod¬ 
ucts  equipped  with  affordable,  user-friendly  safe¬ 
guards.  Many  individual  products  and  techniques 
are  available  to  adequately  safeguard  specific  in¬ 
formation  networks,  if  the  user  knows  what  to  pur¬ 
chase  and  can  afford  and  correctly  use  the  product. 
Nevertheless,  better  and  more  affordable  products 
are  needed.  In  particular,  OTA  found  a  need  for 
products  that  integrate  security  features  with  oth¬ 
er  functions  for  use  in  electronic  commerce,  elec¬ 
tronic  mail,  or  other  applications. 

OTA  found  that  more  study  is  needed  to  fully  un¬ 
derstand  vendors’  responsibilities  with  respect  to 
software  and  hardware  product  quality  and  liabil¬ 
ity.  OTA  also  found  that  more  study  is  also  needed 
on  the  effects  of  export  controls  on  the  domestic 
and  global  markets  for  information  safeguards, 
and  on  the  ability  of  safeguard  developers  and 
vendors  to  produce  more  affordable,  integrated 
products.  OTA  concluded  that  broader  efforts  to 
safeguard  networked  information  will  be  frus¬ 
trated  unless  cryptography-policy  issues  are  re¬ 
solved. 

OTA  found  that  the  single  most  important  step 
toward  implementing  proper  safeguards  for  net¬ 
worked  information  in  a  federal  agency  or  other 
organization  is  for  top  management  to  define  the 
organization’s  overall  objectives,  define  an  orga¬ 
nizational  security  policy  to  reflect  those  objec¬ 
tives,  and  implement  that  policy.  Only  top 
management  can  consolidate  the  consensus  and 
apply  the  resources  necessary  to  effectively  pro¬ 
tect  networked  information.  For  the  federal  gov¬ 
ernment,  this  requires  guidance  from  the  Office  of 
Management  and  Budget  (OMB)  (e.g.,  in  OMB 
Circular  A- 130),  commitment  from  top  agency 
management,  and  oversight  by  Congress.  The 
1994  OTA  report  found  that  in  practice,  there  have 
historically  been  both  insufficient  incentives  for 
compliance,  as  well  as  insufficient  sanctions  for 
noncompliance,  with  the  spirit  of  the  Computer 
Security  Act. 


During  the  course  of  the  OTA  assessment 
(1993-94),  there  was  widespread  controversy  con¬ 
cerning  the  Clinton  Administration’s  escrowed- 
encryption  initiative.  The  significance  of  this 
initiative,  in  concert  with  other  federal  cryptogra¬ 
phy  policies,  resulted  in  an  increased  focus  in  the 
report  on  the  processes  that  the  government  uses 
to  regulate  cryptography  and  to  develop  federal 
information  processing  standards  (FIPS)  based  on 
cryptography. 

The  1994  report  focused  on  policy  issues  in  three 
areas:  1)  cryptography  policy,  including  federal 
information  processing  standards  and  export  con¬ 
trols;  2)  guidance  on  safeguarding  unclassified  in¬ 
formation  in  federal  agencies;  and  3)  legal  issues 
and  information  security,  including  electronic 
commerce,  privacy,  and  intellectual  property.  The 
following  sections  present  the  issues  and  options 
from  that  report. 

NATIONAL  CRYPTOGRAPHY  POLICY4 

The  1994  OTA  report  concluded  that  Congress 
has  vital  strategic  roles  in  cryptography  policy 
and,  more  generally,  in  safeguarding  information 
and  protecting  personal  privacy  in  a  networked  so¬ 
ciety.  Because  cryptography  has  become  a 
technology  of  broad  application,  decisions  about 
cryptography  policy  have  increasingly  broad  ef¬ 
fects  on  society.  Federal  standards  (e.g.,  the  feder¬ 
al  information  processing  standards,  or  the  FIPS) 
and  export  controls  have  substantial  significance 
for  the  development  and  use  of  these  technologies. 

I  Congressional  Review  and 
Open  Processes 

In  1993,  having  recognized  the  importance  of 
cryptography  and  the  policies  that  govern  the  de¬ 
velopment,  dissemination,  and  use  of  the  technol¬ 
ogy,  Congress  asked  the  National  Research 
Council  (NRC)  to  conduct  a  major  study  that 
would  support  a  broad  review  of  cryptography  and 


4  See  Information  Security  and  Privacy  in  Network  Environments,  OTA-TCT-606  (Washington,  DC;  U.S.  Government  Printing  Office,  Sep- 
tember  1994),  pp.  8-18. 
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its  deployment.5  An  important  outcome  of  this  re¬ 
view  of  national  cryptography  policy  would  be  the 
development  of  more  open  processes  to  determine 
how  cryptography  will  be  deployed  throughout 
society.  Cryptography  deployment  includes  de¬ 
velopment  of  the  public-key  infrastructures  and 
certification  authorities  that  will  support  electron¬ 
ic  delivery  of  government  services,  copyright 
management,  and  digital  commerce. 

The  results  of  the  NRC  study  are  expected  to  be 
available  in  1996.  But,  given  the  speed  with  which 
the  Clinton  Administration  is  acting  to  deploy  es¬ 
crowed  encryption  within  the  government,  OTA 
concluded  that  information  to  support  a  congres¬ 
sional  policy  review  of  cryptography  is  out  of 
phase  with  implementation.  Therefore,  OTA 
noted  that: 

OPTION:  Congress  could  consider  placing  a 
hold  on  further  deployment  ofkey-escrow  encryp¬ 
tion,  pending  a  congressional  policy  review. 

More  open  processes  would  build  trust  and  con¬ 
fidence  in  government  operations  and  leadership. 
More  openness  would  allow  diverse  stakeholders 
to  understand  how  their  views  and  concerns  were 
being  balanced  with  those  of  others,  in  establish¬ 
ing  an  equitable  deployment  of  these  technolo¬ 
gies,  even  when  some  of  the  specifics  of  the 
technology  remain  classified.  (See  also  the  policy 
section  below  on  safeguarding  information  in  fed¬ 
eral  agencies.)  More  open  processes  would  also 
allow  for  public  consensus-building,  providing 
better  information  for  use  in  congressional  over¬ 
sight  of  agency  activities.  Toward  these  ends, 
OTA  noted  that: 

OPTION:  Congress  could  address  the  extent  to 
which  the  current  working  relationship  between 
NIST  and  NSA  will  be  a  satisfactory  part  of  this 
open  process,  or  the  extent  to  which  the  current 
arrangements  should  be  reevaluated  and  revised. 

Another  important  outcome  of  a  broad  policy  re¬ 
view  would  be  a  clarification  of  national  informa¬ 
tion-policy  principles  in  the  face  of  technological 
change: 


OPTION:  Congress  could  state  its  policy  as  to 
when  the  impacts  of  a  technology  (like  cryptogra¬ 
phy)  are  so  powerful  and  pervasive  that  legisla¬ 
tion  is  needed  to  provide  sufficient  public  visibility 
and  accountability  for  government  actions. 

During  the  assessment,  OTA  found  that  many  of 
the  persistent  concerns  surrounding  the  Escrowed 
Encryption  Standard,  and  the  Clinton  Administra¬ 
tion’s  escrowed-encryption  initiative  generally, 
focused  on  whether  key-escrow  encryption  will 
become  mandatory  for  government  agencies  or 
the  private  sector,  if  nonescrowed  encryption  will 
be  banned,  and/or  if  these  actions  could  be  taken 
without  legislation.  Other  concerns  still  focus  on 
whether  or  not  alternative  forms  of  encryption 
would  be  available  that  would  allow  private  indi¬ 
viduals  and  organizations  the  option  of  depositing 
keys  (or  not)  with  one  or  more  third-party  trust¬ 
ees — at  their  discretion.  The  National  Research 
Council  study  should  be  valuable  in  helping  Con¬ 
gress  to  understand  the  broad  range  of  technical 
and  institutional  alternatives  available  for  various 
types  of  trusteeships  for  cryptographic  keys,  “dig¬ 
ital  powers  of  attorney,”  and  the  like.  However,  if 
implementation  of  the  EES  and  related  technolo¬ 
gies  continues  at  the  current  pace,  OTA  noted  that 
key-escrow  encryption  may  already  be  embedded 
in  information  systems  before  Congress  can  act  on 
the  NRC  report. 

I  Export  Controls  on  Cryptography 

As  part  of  a  broad  national  cryptography  policy, 
OTA  noted  that  Congress  may  wish  to  periodical¬ 
ly  examine  export  controls  on  cryptography,  to  en¬ 
sure  that  these  continue  to  reflect  an  appropriate 
balance  between  the  needs  of  signals  intelligence 
and  law  enforcement  and  the  needs  of  the  public 
and  business  communities.  This  examination 
would  take  into  account  changes  in  foreign  capa¬ 
bilities  and  foreign  availability  of  cryptographic 
technologies. 


5  For  information  about  the  NRC  study,  contact  Herb  Lin  at  the  National  Research  Council  (crypto@nas.edu). 
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Information  from  an  executive  branch  study  of 
the  encryption  market  and  export  controls  that 
was  promised  by  Vice  President  Gore  should  pro¬ 
vide  some  near-term  information.6  At  this  writ¬ 
ing,  the  Commerce  Department  and  the  National 
Security  Agency  (NSA)  are  assessing  the  eco¬ 
nomic  impact  of  U.S.  export  controls  on  the  U.S. 
computer  software  industry;  as  part  of  this  study, 
NSA  is  determining  the  foreign  availability  of  en¬ 
cryption  products.7  The  study  is  scheduled  to  be 
delivered  to  National  Security  Council  (NSC)  de¬ 
puties  by  July  1,  1995.  It  is  anticipated  that  there 
will  be  both  unclassified  and  classified  portions  of 
the  study;  there  may  be  some  public  release  of  the 
unclassified  material.8 

OTA  noted  that  the  scope  and  methodology  of 
the  export-control  studies  that  Congress  might 
wish  to  use  in  the  future  may  differ  from  those 
used  in  the  executive  branch  study.  Therefore: 

OPTION:  Congress  might  wish  to  assess  the  va¬ 
lidity  and  effectiveness  of  the  Clinton  Administra¬ 
tion  s  studies  of  export  controls  on  cryptography 
by  conducting  oversight  hearings ,  by  undertaking 
a  staff  analysis,  or  by  requesting  a  study  from  the 
Congressional  Budget  Office . 

I  Congressional  Responses  to 
Escrowed-Encryption  Initiatives 

OTA  also  recognized  that  Congress  also  has  a 
more  near-term  role  to  play  in  determining  the 
extent  to  which — and  how — the  Escrowed  En¬ 
cryption  Standard  (EES)  and  other  escrowed-en¬ 
cryption  systems  will  be  deployed  in  the  United 
States.  These  actions  can  be  taken  within  a  long¬ 
term,  strategic  framework.  Congressional  over¬ 
sight  of  the  effectiveness  of  policy  measures  and 
controls  can  allow  Congress  to  revisit  these  issues 
as  needed,  or  as  the  consequences  of  previous  de¬ 
cisions  become  more  apparent. 

The  Escrowed  Encryption  Standard  (Clipper) 
was  issued  as  a  voluntary  FIPS;  use  of  the  EES  by 


the  private  sector  is  also  voluntary.  The  Clinton 
Administration  has  stated  that  it  has  no  plans  to 
make  escrowed  encryption  mandatory,  or  to  ban 
other  forms  of  encryption.  But,  absent  legislation, 
these  intentions  are  not  binding  for  future  admin¬ 
istrations  and  also  leave  open  the  question  of  what 
will  happen  if  the  EES  and  related  technologies  do 
not  prove  acceptable  to  the  private  sector.  More¬ 
over,  the  executive  branch  may  soon  be  using  the 
EES  and/or  related  escrowed-encryption  technol¬ 
ogies  to  safeguard — among  other  things — large 
volumes  of  private  information  about  individuals 
(e.g.,  taxpayer  data  and  health  care  information). 

For  these  reasons,  OTA  concluded  that  the  EES 
and  other  key-escrowing  initiatives  are  by  no 
means  only  an  executive  branch  concern.  The 
EES  and  any  subsequent  escrowed-encryption 
standards  (e.g.,  for  data  communications  in  com¬ 
puter  networks,  or  for  file  encryption)  also  war¬ 
rant  congressional  attention  because  of  the  public 
funds  that  will  be  spent  in  deploying  them.  More¬ 
over,  negative  public  perceptions  of  the  EES  and 
the  processes  by  which  encryption  standards  are 
developed  and  deployed  may  erode  public  confi¬ 
dence  and  trust  in  government  and,  consequently, 
the  effectiveness  of  federal  leadership  in  promot¬ 
ing  responsible  safeguard  use. 

In  responding  to  current  escrowed-encryption 
initiatives  like  the  EES,  and  in  determining  the  ex¬ 
tent  to  which  appropriated  funds  should  be  used  in 
implementing  key-escrow  encryption  and  related 
technologies,  OTA  noted  that: 

OPTION:  Congress  could  address  the  appropri¬ 
ate  locations  of  the  key-escrow  agents,  particular¬ 
ly  for  federal  agencies ,  before  additional 
investments  are  made  in  staff  and  facilities  for 
them..  Public  acceptance  of  key-escrow  encryption 
might  be  improved — but  not  assured — by  an  es¬ 
crowing  system  that  used  separation  of  powers  to 
reduce  perceptions  of  the  potential  for  misuse. 


6  Vice  President  A1  Gore,  letter  to  Representative  Maria  Cantwell,  July  20,  1994.  See  OTA,  op.  cit.,  footnote  4,  pp.  11-13. 

7  Maurice  Cook,  Bureau  of  Export  Administration,  Economic  Analysis  Division,  personal  communication,  Mar.  7,  1995. 

8  Bill  Clements,  National  Security  Council,  personal  communication,  Mar.  21,  1995. 
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With  respect  to  current  escrowed-encryption  ini¬ 
tiatives  like  the  EES,  as  well  as  any  subsequent 
key-escrow  encryption  initiatives  (e.g.,  for  data 
communications  or  file  encryption),  and  in  deter¬ 
mining  the  extent  to  which  appropriated  funds 
should  be  used  in  implementing  key-escrow  en¬ 
cryption  and  related  technologies,  OTA  noted 
that: 

OPTION:  Congress  could  address  the  issue  of 
criminal  penalties  for  misuse  and  unauthorized 
disclosure  of  escrowed  key  components. 

OPTION:  Congress  could  consider  allowing 
damages  to  be  awarded  for  individuals  or  orga¬ 
nizations  who  were  harmed  by  misuse  or  unautho¬ 
rized  disclosure  of  escrowed  key  components. 

SAFEGUARDING  INFORMATION 
IN  FEDERAL  AGENCIES9 

Congress  has  an  even  more  direct  role  in  establish¬ 
ing  the  policy  guidance  within  which  federal 
agencies  safeguard  information,  and  in  oversight 
of  agency  and  OMB  measures  to  implement  in¬ 
formation  security  and  privacy  requirements.  The 
Office  of  Management  and  Budget  is  responsible 
for  developing  and  implementing  government- 
wide  policies  for  information  resource  manage¬ 
ment;  for  overseeing  the  development  and 
promoting  the  use  of  government  information- 
management  principles,  standards,  and  guide¬ 
lines;  and  for  evaluating  the  adequacy  and 
efficiency  of  agency  information-management 
practices.  During  the  assessment,  OTA  found  that 
information-security  managers  in  federal  agen¬ 
cies  must  compete  for  resources  and  support  to 
properly  implement  needed  safeguards.  For  their 
efforts  to  succeed,  both  OMB  and  top  agency 
management  must  fully  support  investments  in 
cost-effective  safeguards.  Given  the  expected  in¬ 
crease  in  interagency  sharing  of  data,  interagency 
coordination  of  privacy  and  security  policies  is 


also  necessary  to  ensure  uniformly  adequate 
protection. 

I  Effectiveness  of  OMB  Guidance 

The  Paperwork  Reduction  Act  of  1 995  was  signed 
by  President  Clinton  on  May  22,  1995.  Both  the 
House  (H.R.  830)  and  Senate  (S.  244)  versions  of 
the  bill  reaffirmed  OMB’s  authorities  under  the 
Computer  Security  Act  for  safeguarding  unclassi¬ 
fied  information.  The  conference  bill 10  containing 
these  provisions  passed  in  both  Houses  on  April  6, 
1995  (see  chapter  4  of  this  background  paper  for 
discussion). 

Appendix  III  (“Security  of  Federal  Automated 
Information  Systems”)  of  the  1985  version  of 
OMB  Circular  A- 130  set  forth  OMB’s  govern¬ 
ment-wide  policy  guidance  for  information  secu¬ 
rity.  At  this  writing,  a  new ;  proposed  revision  of 
Appendix  III  has  just  been  issued.  The  proposed 
revision  is  intended  to  lead  to  improved  federal  in¬ 
formation-security  practices  and  to  make  fulfill¬ 
ment  of  Computer  Security  Act  and  Privacy  Act 
requirements  more  effective  generally,  as  well  as 
with  respect  to  data  sharing  and  secondary  uses. 

The  new,  proposed  revision  of  Appendix  III 
(“Security  of  Federal  Automated  Information”) 
will  be  key  to  assessing  the  prospect  for  improved 
federal  information  security  practices.  The  pro¬ 
posed  revision  was  presented  for  comment  at  the 
end  of  March  1995.  According  to  OMB,  the  pro¬ 
posed  new  government-wide  guidance: 

...  is  intended  to  guide  agencies  in  securing  in¬ 
formation  as  they  increasingly  rely  on  an  open  and 
interconnected  National  Information  Infrastruc¬ 
ture.  It  stresses  management  controls  such  as  indi¬ 
vidual  responsibility,  awareness  and  training,  and 
accountability,  rather  than  technical  con¬ 
trols.  .  .  The  proposal  would  also  better  integrate 
security  into  program  and  mission  goals,  reduce  the 
need  for  centralized  reporting  of  paper  security 
plans,  emphasize  the  management  of  risk  rather 


9  See  OTA,  op.  cit.,  footnote  4,  pp.  18-20. 

10  See  U.S.  Congress,  House  of  Representatives,  “Paperwork  Reduction  Act  of  1995— Conference  Report  to  Accompany  S.244,”  H.Rpt. 
104-99,  Apr.  3,  1995.  These  provisions  are  found  in  44U.S.C.  section  3504. 
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than  its  measurement,  and  revise  government-wide 
security  responsibilities  to  be  consistent  with  the 
Computer  Security  Act.11 

See  chapter  4  of  this  background  paper  for  discus¬ 
sion  of  the  proposed  revision  to  Appendix  III.  The 
issues  and  options  presented  below  are  in  the  con¬ 
text  of  the  1994  report  and  the  1985  Appendix  III. 
However,  OTA  expects  that  congressional  over¬ 
sight  and  analysis  as  indicated  below  will  remain 
useful  for  understanding  OMB’s  new  guidance 
and  assessing  its  potential  effectiveness. 

Because  the  revised  Appendix  III  had  not  been 
issued  by  the  time  Information  Security  and  Pri¬ 
vacy  in  Network  Environments  was  completed  in 
1994,  the  OTA  report  was  unable  to  assess  the  re¬ 
vision’s  potential  for  improving  information  secu¬ 
rity  in  federal  agencies,  for  holding  agency 
managers  accountable  for  security,  or  for  ensuring 
uniform  protection  in  light  of  data  sharing  and 
secondary  uses.  OTA  noted  that,  after  the  revised 
Appendix  III  of  OMB  Circular  A-130  is  issued: 

OPTION:  Congress  could  assess  the  effective¬ 
ness  of  the  OMB ’s  revised  guidelines,  including 
improvements  in  implementing  the  Computer  Se¬ 
curity  Act’s  provisions  regarding  agency  security 
plans  and  training,  in  order  to  determine  whether 
additional  statutory  requirements  or  oversight 
measures  are  needed. 

This  might  be  accomplished  by  conducting 
oversight  hearings,  undertaking  a  staff  analysis, 
and/or  requesting  a  study  from  the  General  Ac¬ 
counting  Office  (GAO).  However,  the  effects  of 
OMB’s  revised  guidance  may  not  be  apparent  for 
some  time  after  the  revised  Appendix  III  is  issued. 

Therefore,  a  few  years  may  pass  before  GAO  is 
able  to  report  government-wide  findings  that 
would  be  the  basis  for  determining  the  need  for 
further  revision  or  legislation.  In  the  interim: 

OPTION:  Congress  could  gain  additional  in¬ 
sight  through  hearings  to  gauge  the  reaction  of 
agencies,  as  well  as  privacy  and  security  experts 


from  outside  government,  to  OMB ’s  revised  guide¬ 
lines. 

Oversight  of  this  sort  might  be  especially  valu¬ 
able  for  agencies,  such  as  the  Internal  Revenue 
Service,  that  are  developing  major  new  informa¬ 
tion  systems.  In  the  course  of  its  oversight  and 
when  considering  the  direction  of  any  new  legisla¬ 
tion,  OTA  noted  that: 

OPTION:  Congress  could  ensure  that  agencies 
include  explicit  provisions  for  safeguarding  in¬ 
formation  assets  in  any  information-technology 
planning  documents. 

OPTION:  Congress  could  ensure  that  agencies 
budget  sufficient  resources  to  safeguard  informa¬ 
tion  assets,  whether  as  a  percentage  of  informa¬ 
tion-technology  modernization  and/or  operating 
budgets,  or  otherwise. 

OPTION:  Congress  could  ensure  that  the  De¬ 
partment  of  Commerce  assigns  sufficient  re¬ 
sources  to  the  National  Institute  of  Standards  and 
Technology  (NIST)  to  support  its  Computer  Secu¬ 
rity  Act  responsibilities,  as  well  as  NIST’s  other 
activities  related  to  safeguarding  information  and 
protecting  privacy  in  networks. 

Regarding  NIST’s  computer-security  budget, 
OTA  did  not  determined  the  extent  to  which  addi¬ 
tional  funding  is  needed,  or  the  extent  to  which 
additional  funding  would  improve  the  overall  ef¬ 
fectiveness  of  NIST’s  information-security  activi¬ 
ties.  However,  in  staff  discussions  and  workshops 
during  the  course  of  the  assessment,  OTA  found 
that  individuals  from  outside  and  within  govern¬ 
ment  repeatedly  noted  that  NIST’s  security  activi¬ 
ties  were  not  proactive  and  that  NIST  often  lagged 
in  providing  useful  and  needed  standards  (the 
FIPS)  and  guidelines.  Many  individuals  from  the 
private  sector  felt  that  NIST’s  limited  resources 
for  security  activities  precluded  NIST  from  doing 
work  that  would  also  be  useful  to  industry.  Addi¬ 
tional  resources,  whether  from  overall  increases  in 
NIST’s  budget  or  otherwise,  could  enhance 


1 1  Office  of  Management  and  Budget,  “Security  of  Federal  Automated  Information,”  Proposed  Revision  of  OMB  Circular  No.  A- 1 30  Ap¬ 
pendix  III  (transmittal  memorandum).  At  this  writing,  the  proposed  revision  of  Appendix  III  was  available  from  NIST  via  World  Wide  Web  at 
http://csrc.ncsl.nist.gov/secplcy  as  <al30app3.txt>. 
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NIST’s  technical  capabilities,  enable  it  to  be  more 
proactive,  and  hence  be  more  useful  to  federal 
agencies  and  to  industry. 

OTA  found  that  NIST  activities  with  respect  to 
standards  and  guidelines  related  to  cryptography 
are  a  special  case,  however.  Increased  funding 
alone  will  not  be  sufficient  to  ensure  NIST’s  tech¬ 
nological  leadership  or  its  fulfillment  of  the  “bal¬ 
ancing”  role  as  envisioned  by  the  Computer 
Security  Act  of  1987.  With  respect  to  cryptogra¬ 
phy,  OTA  concluded  that  national  security 
constraints  set  forth  in  executive  branch  policy  di¬ 
rectives  appear  to  be  binding.  These  constraints 
have  resulted,  for  example,  in  the  closed  processes 
by  which  the  Escrowed  Encryption  Standard 
(Clipper)  was  developed  and  implemented.  In¬ 
creased  funding  could  enable  NIST  to  become  a 
more  equal  partner  to  NSA,  at  least  in  deploying 
(if  not  developing)  cryptographic  standards.  But, 
if  NIST/NSA  processes  and  outcomes  are  to  re¬ 
flect  a  different  balance  of  national  security  and 
other  public  interests,  or  more  openness,  than  has 
been  evidenced  over  the  past  five  years,  OTA  con¬ 
cluded  that  clear  policy  guidance  and  oversight 
(not  just  funding)  will  be  needed. 

LEGAL  ISSUES  AND 
INFORMATION  SECURITY 

The  laws  currently  governing  commercial  trans¬ 
actions,  data  privacy,  and  intellectual  property 
were  largely  developed  for  a  time  when  tele¬ 
graphs,  typewriters,  and  mimeographs  were  the 
commonly  used  office  technologies  and  business 
was  conducted  with  paper  documents  sent  by 
mail.  Technologies  and  business  practices  have 
dramatically  changed,  but  the  law  has  been  slower 
to  adapt.  Computers,  electronic  networks,  and  in¬ 
formation  systems  are  now  used  to  routinely  proc¬ 
ess,  store,  and  transmit  digital  data  in  most 
commercial  fields.  OTA  found  that  changes  in 
communication  and  information  technologies 
were  particularly  significant  in  three  areas:  elec¬ 


tronic  commerce,  privacy  and  transborder  data 
flow,  and  digital  libraries. 

I  Electronic  Commerce 

As  businesses  replace  conventional  paper  docu¬ 
ments  with  standardized  computer  forms,  the 
need  arises  to  secure  the  transactions  and  establish 
means  to  authenticate  and  provide  nonrepudiation 
services  for  electronic  transactions,  that  is,  a 
means  to  establish  authenticity  and  certify  that  the 
transaction  was  made.  Absent  a  signed  paper  doc¬ 
ument  on  which  any  nonauthorized  changes  could 
be  detected,  a  digital  signature  to  prevent,  avoid, 
or  minimize  the  chance  that  the  electronic  docu¬ 
ment  has  been  altered  must  be  developed.  In  con¬ 
trast  to  the  courts’  treatment  of  conventional, 
paper-based  transactions  and  records,  little  guid¬ 
ance  is  offered  as  to  whether  a  particular  safeguard 
technique,  procedure,  or  practice  will  provide  the 
requisite  assurance  of  enforceability  in  electronic 
form.  This  lack  of  guidance  concerning  security 
and  enforceability  is  reflected  in  the  diversity  of 
security  and  authentication  practices  used  by 
those  involved  in  electronic  commerce. 

Legal  standards  for  electronic  commercial  trans¬ 
actions  and  digital  signatures  have  not  been  fully 
developed,  and  these  issues  have  undergone  little 
review  in  the  courts.  Therefore,  OTA  noted  that 
immediate  action  by  Congress  might  not  be  war¬ 
ranted.12  However,  OTA  noted  the  need  for  con¬ 
gressional  awareness  of  these  issues: 

OPTION:  Congress  could  monitor  the  issue  of 
legal  standards  for  electronic  transactions  and 
digital  signatures,  so  that  these  are  considered  in 
future  policy  decisions  about  information  secu¬ 
rity. 

Such  attention  would  be  especially  timely,  given 
the  increasing  focus  of  the  national  and  interna¬ 
tional  legal  communities  and  the  states  on  devel¬ 
oping  legal  standards  for  electronic  commerce,  as 
well  as  guidelines  and  model  legislation  for  digi¬ 
tal  signatures. 


12  Note  this  refers  to  legal  standards  for  contracts,  rules  of  evidence,  and  so  forth,  not  to  specific  technical  standards  like  the  DSS. 
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For  example,  the  American  Bar  Association’s 
(ABA)  Information  Security  Committee,  Science 
and  Technology  Section,  is  drafting  “Global  Digi¬ 
tal  Signature  Guidelines  and  model  legislation. 
The  ABA  effort  includes  federal-agency  represen¬ 
tatives,  as  well  as  representatives  from  the  private 
sector  and  other  governments.  With  participation 
by  the  International  Chamber  of  Commerce  and 
the  U.S.  State  Department,  the  United  Nations 
Commission  on  International  Trade  Law  has  com¬ 
pleted  a  Model  Law  on  electronic  data  interchange 
(EDI).13 

Utah  has  just  enacted  digital  signature  legisla¬ 
tion.  The  Utah  Digital  Signature  Act14  is  intended 
to  provide  a  reliable  means  for  signing  computer- 
based  documents  and  to  provide  legal  recognition 
of  digital  signatures  using  “strong  authentication 
techniques”  based  on  asymmetric  cryptography. 
To  assure  a  minimum  level  of  reliability  in  digital 
signatures,  the  Utah  statute  provides  for  the  li¬ 
censing  and  regulation  of  certification  authorities 
by  a  “Digital  Signature  Agency”  (e.g.,  the  Divi¬ 
sion  of  Corporations  and  Commercial  Code  of  the 
Utah  Department  of  Commerce).  The  act,  first 
drafted  as  a  proposed  model  law,  provides  that  the 
private  key  is  the  property  of  the  subscriber  who 
rightfully  holds  it  (and  who  has  a  duty  to  keep  it 
confidential);  thus,  tort  or  criminal  actions  are 
possible  for  theft  or  misuse.  It  is  technology-inde¬ 
pendent;  that  is,  it  does  not  mandate  use  of  a  spe¬ 
cific  signature  technique,  although  it  envisions 
use  of  signatures  based  on  standards  similar  to  or 


including  the  ANSI  X.9.30  or  ITU  X.509  stan¬ 
dards.15  (Also  see  discussion  in  chapter  4  of  this 
background  paper.) 

Liability  issues  are  also  important  to  the  devel¬ 
opment  of  electronic  commerce  and  the  underpin¬ 
ning  institutional  infrastructures,  including  (but 
not  limited  to)  escrow  agents  for  key-escrowed 
encryption  systems  and  certificate  authorities  for 
public-key  infrastructures.  Widespread  use  of  cer¬ 
tificate-based,  public-key  infrastructures  will  re¬ 
quire  resolution  and  harmonization  of  liability 
requirements  for  trusted  entities,  whether  these  be 
federal  certificate  authorities,  private  certificate 
(or  “certification”)  authorities,  escrow  agents, 
banks,  clearinghouses,  value-added  networks,  or 
other  entities.16 

I  Protection  of  Privacy  in  Data 

Since  the  1970s,  the  United  States  has  concen¬ 
trated  its  efforts  to  protect  the  privacy  of  personal 
data  collected  and  archived  by  the  federal  govern¬ 
ment.  Rapid  development  of  networks  and  in¬ 
formation  processing  by  computer  now  makes  it 
possible  for  large  quantities  of  personal  informa¬ 
tion  to  be  acquired,  exchanged,  stored,  and 
matched  very  quickly.  As  a  result,  a  market  for 
computer-matched  personal  data  has  expanded 
rapidly,  and  a  private  sector  information  industry 
has  grown  around  the  demand  for  such  data. 

OTA  found  that  increased  computerization  and 
linkage  of  information  maintained  by  the  federal 


13  Information  on  ABA  and  United  Nations  activities  provided  by  Michael  Baum,  Principal,  Independent  Monitoring,  personal  commu¬ 
nication,  Mar.  19, 1995.  See  also  Michael  S.  Baum,  Federal  Certification  Authority  Liability  and  Policy:  Law  and  Policy  of  Certificate-Based 
Public  Key  and  Digital  Signatures,  NIST-GCR-94-654,  NTIS  Doc.  No.  PB94- 191-202  (Springfield,  VA:  National  Technical  Information  Ser- 
vice,  1994). 

14  Utah  Digital  Signature  Legislative  Facilitation  Committee,  “Utah  Digital  Signature  Legislation,”  Dec.  21, 1994.  The  Utah  Digital  Signa¬ 
ture  Act  act  was  signed  into  law  on  Mar.  10,  1995,  as  section  46-3-101  et  seq..  Utah  Code  Annotated.  (Prof.  Lee  Hollaar,  University  of  Utah, 
personal  communication,  Mar.  22,  1995.) 

15  Utah  Digital  Signature  Act,  ibid.  The  model  legislation  was  endorsed  by  the  American  Bar  Association,  Information  Security  Committee 
of  the  Science  and  Technology  Section,  EDI/Information  Technology  Division;  Prof.  Lee  Hollaar,  University  of  Utah;  Salt  Lake  Legal  Defend¬ 
ers  Assoc.;  Statewide  Association  of  Public  Attorneys;  Utah  Attorney  General’s  Office;  Utah  Dept,  of  Corrections;  Utah  Information  Technolo¬ 
gy  Commission;  Utah  Judicial  Council;  and  Utah  State  Tax  Commission. 

16  See  Michael  Baum,  op.  cit.,  footnote  1 2  for  discussion  of  liability  exposure,  legal  considerations,  tort  and  contract  remedies,  government 
consent  to  be  liable,  and  recommendations  and  approaches  to  mitigate  liability. 
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government  is  arguably  not  addressed  by  the  Pri¬ 
vacy  Act,  which  approaches  privacy  issues  on  an 
agency-by-agency  basis.  To  address  these  devel¬ 
opments,  OTA  noted  several  alternatives: 

OPTION:  Congress  could  allow  each  agency  to 
address  privacy  concerns  individually,  through  its 
present  system  of  review  boards. 

OPTION:  Congress  could  require  agencies  to 
improve  the  existing  data  integrity  boards ,  with  a 
charter  to  make  clearer  policy  decisions  about 
sharing  information  and  maintaining  its  integrity. 

OPTION:  Congress  could  amend  the  existing 
law  to  include  provisions  addressing  the  sharing 
and  matching  of  data,  or  restructure  the  law  over¬ 
all  to  track  the  flow  of  information  between  insti¬ 
tutions . 

OPTION:  Congress  could  provide  for  public  ac¬ 
cess  for  individuals  to  information  about  them¬ 
selves,  and  protocols  for  amendment  and 
correction  of  personal  information.  It  could  also 
consider  providing  for  online  publication  of  the 
Federal  Register  to  improve  public  notice  about 
information  collection  and  practices . 

OTA  noted  that,  in  deciding  between  courses  of 
actions,  Congress  could  exercise  its  responsibility 
for  oversight  through  hearings  and/or  investiga¬ 
tions,  gathering  information  from  agency  officials 
involved  in  privacy  issues,  as  well  as  citizens,  in 
order  to  gain  a  better  understanding  of  what  kinds 
of  actions  are  required  to  implement  better  custo¬ 
dianship,  a  minimum  standard  of  quality  for  pri¬ 
vacy  protection,  and  notice  to  individuals  about 
use  and  handling  of  information. 

Although  the  United  States  does  not  comprehen¬ 
sively  regulate  the  creation  and  use  of  such  data  in 
the  private  sector,  foreign  governments  (particu¬ 
larly  the  European  Union)  do  impose  controls. 
The  Organization  for  Economic  Cooperation  and 
Development  (OECD)  adopted  guidelines  in 
1980  to  protect  the  privacy  and  transborder  flows 
of  personal  data.  The  difference  between  the  level 
of  personal  privacy  protection  in  the  United  States 
and  that  of  its  trading  partners,  who  in  general 
more  rigorously  protect  privacy,  could  inhibit  the 
exchange  of  data  with  these  countries.  U.S.  busi¬ 
ness  has  some  serious  concerns  about  the  Euro¬ 
pean  Union  (EU)  proposal,  as  it  relates  to  the  data 


subject’s  consent  and  the  transfer  of  data  to  non- 
EU  countries.  OTA  noted  that  Congress  had  a 
choice  when  addressing  the  sufficiency  of  existing 
U.S.  legal  standards  for  privacy  and  security  in  a 
networked  environment  for  the  private  sector: 

OPTION:  Congress  could  legislate  to  set  stan¬ 
dards  similar  to  the  OECD  guidelines; 

or, 

OPTION:  Congress  could  allow  individual  in¬ 
terests,  such  as  the  business  community,  to  advise 
the  international  community  on  its  own  of  its  in¬ 
terests  in  data  protection  policy.  However,  be¬ 
cause  the  EU's  protection  scheme  could  affect 
U.S.  trade  in  services  and  could  impact  upon  indi¬ 
viduals,  Congress  may  also  wish  to  monitor  and 
consider  the  requirements  of  foreign  data  protec¬ 
tion  rules  as  they  shape  U.S.  security  and  privacy 
policy  to  assure  that  all  interests  are  reflected. 

OTA  noted  that  a  diversity  of  interests  must  be 
reflected  in  addressing  the  problem  of  maintain¬ 
ing  privacy  in  computerized  information — 
whether  in  the  public  or  private  sector.  To  deal 
with  this,  OTA  noted  that: 

OPTION:  Congress  could  establish  a  Federal 
Privacy  Commission. 

Proposals  for  such  a  commission  or  board  were 
previously  discussed  by  OTA  in  its  1986  report 
Electronic  Record  Systems  and  Individual  Priva¬ 
cy.  In  that  study,  OTA  cited  the  lack  of  a  federal  fo¬ 
rum  in  which  the  conflicting  values  at  stake  in  the 
development  of  federal  electronic  systems  could 
be  fully  debated  and  resolved.  As  privacy  ques¬ 
tions  will  arise  in  the  domestic  arena,  as  well  as  in¬ 
ternationally,  a  commission  could  deal  with  these 
as  well. 

I  Protection  of  Intellectual  Property  in  the 
Administration  of  Digital  Libraries 

OTA  found  that  the  availability  of  protected  intel¬ 
lectual  property  in  digital  libraries  and  other  net¬ 
worked  information  collections  is  straining  the 
traditional  methods  of  protection  and  payment  for 
use  of  intellectual  property.  Technologies  (like 
digital  signatures  and  encryption)  developed  for 
safeguarding  information  might  also  hold  prom¬ 
ise  for  monitoring  the  use  of  copyrighted  informa- 
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tion  and  facilitating  means  for  collecting  royalties 
and  compensating  the  copyright  holders.  The  ap¬ 
plication  of  intellectual-property  law  to  protect 
works  maintained  in  digital  libraries  continues  to 
be  problematic;  traditional  copyright  concepts 
such  as  fair  use  are  not  clearly  defined  as  they  ap¬ 
ply  to  these  works;  and  the  means  to  monitor  com¬ 
pliance  with  copyright  law  and  to  distribute 
royalties  is  not  yet  resolved. 

OTA  had  addressed  these  legal  and  institutional 
issues  in  an  earlier  report,  Finding  a  Balance: 
Computer  Software,  Intellectual  Property,  and  the 
Challenge  of  Technological  Change.  The  1992  re¬ 
port  included  several  options  to  deal  with  the  use 
of  works  in  electronic  form. 

During  the  1994  assessment,  OTA  found  that  the 
widespread  development  of  multimedia  authoring 
tools — integrating  film  clips,  images,  music, 
sound,  and  other  content — raises  additional  issues 
pertaining  to  copyright  and  royalties.  With  respect 
to  copyright  for  multimedia  works,  OTA  noted 
that: 

OPTION:  Congress  could  allow  the  courts  to 
continue  to  define  the  law  of  copyright  as  it  is  ap¬ 
plied  in  the  world  of  electronic  information; 

or, 

OPTION:  Congress  could  take  specific  legisla¬ 
tive  action  to  clarify  and  further  define  the  copy¬ 
right  law  in  the  world  of  electronic  information. 

Instead  of  waiting  for  legal  precedents  to  be  es¬ 
tablished  or  developing  new  legislation,  OTA 


noted  that  Congress  might  try  a  third  approach 
that  would  allow  producer  and  user  communities 
to  establish  common  guidelines  for  use  of  copy¬ 
righted,  multimedia  works: 

OPTION:  Congress  could  allow  information 
providers  and  purchasers  to  enter  into  agreements 
that  would  establish  community  guidelines  with¬ 
out  having  the  force  of  law.  In  so  doing,  Congress 
could  decide  at  some  point  in  the  future  to  review 
the  success  of  such  an  approach. 

More  generally,  with  respect  to  private  sector 
solutions  for  problems  concerning  rights  and  roy¬ 
alties  for  copyrighted  works  in  electronic  form, 
OTA  noted  that: 

OPTION:  Congress  could  encourage  private  ef¬ 
forts  to  form  rights-clearing  and  royalty-collec¬ 
tion  agencies  for  groups  of  copyright  owners. 

Alternatively, 

OPTION:  Congress  might  allow  private  sector 
development  of  network  tracking  and  monitoring 
capabilities  to  support  a  fee-for-use  basis  for 
copyrighted  works  in  electronic  form. 

In  the  latter  case,  Congress  might  wish  to  review 
whether  a  fee-for-use  basis  for  copyrighted  works 
in  electronic  form  is  workable,  from  the  stand¬ 
point  of  both  copyright  law  and  technological  ca¬ 
pabilities.  OTA  suggested  that  this  might  be 
accomplished  by  conducting  oversight  hearings, 
undertaking  a  staff  analysis,  and/or  requesting  a 
study  from  the  Copyright  Office. 
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